Transcription
Hello my dears. I know that a lot of beginners watch this channel, and for beginners in programming, there are usually a lot of questions. Well, because you enter some unfamiliar world in which everything is strange, difficult, a nightmare. You look at what you need to learn, not only a programming language but also frameworks. And here there are also some tools. Well, okay, let's say it's understandable to any developer, even the most beginner. Well, a code editor, you write code in it, like everything is clear. And version control systems, the terrible Git, it's like, why is this, like, what? And why? Well, do you need to learn it? And how much do you need to? Well, all sorts of such fears and horrors. If you are an experienced developer, you are unlikely to find anything new in this video. But if you are a beginner, I hope this video will be very useful. Today we will discuss what Git is and why it is needed. Let's go. First, let's start, in fact, with the definition. Yes, Git is used, like any other version control system, about which a little later. It is used to track changes in source code during software development and allows multiple developers to collaborate effectively on a project. This is, so to speak, a, you know, official definition. Let's talk about why it is needed at all and what happens with all this. First, when you are just a developer by yourself, alone with your code, for example, you are learning and writing your famous "Hello, world!". I wrote "Hello, world!", it's all good and wonderful. You can calmly use the tools of your IDE, or even if you just use some editor, and press Ctrl+Z to roll back to the previous state. For example, you did something wrong, you need to go back and, in fact, fix it. No problem. But probably, if you have already started learning programming even a little, you have probably noticed that even the smallest program rarely consists of one file. Usually, you have several. Moreover, as soon as you start learning and start figuring all this out, you will notice that almost every edit you make in your code, you do it not in one file, but in several at once. Here you fixed something, here you added something, here you deleted something, here you renamed something. This is one edit, and you understand that to roll back to the previous state is very difficult, even if your editor supports the ability to roll back in several files. Yes, most programming editors can do this, if not all, then still, you understand that stopping at the moment when you just started doing this is very difficult because it's unclear, where are the previous changes before this edit, and where are the next ones, especially if you need to roll back not one change, but several such changes through several files. You roll back one, and therefore you press Ctrl+Z, Shift+Z, or Ctrl+Y, whatever is in your application, and you roll back back and forth in an attempt to understand where you actually stopped. And writing a program for beginners, I'm telling you, it consists of constantly experimenting. You try one thing, you try another, you try a third. The first, second, third didn't work, you need to roll it back and move in another direction. Thus, we get that working on a program is always working on moving forward, moving backward, moving forward, moving backward, all the time in different directions until it works. Therefore, for a programmer, the most important skill and the most important property of this editor is the ability to roll back and forth. But look, what if, for example, you have been working on a project for a long time, a large one, and you need, for example, to roll back to what you were doing a week ago because you have already realized that you have been doing nonsense for a whole week and went the wrong way, and it doesn't work like that. Well, sorry, but I don't even want to think how many times you will have to press Ctrl+Z to roll back to that state. Most likely, your system in the editor simply does not remember such a quality of changes. Moreover, you have surely closed it, restarted the computer, done many other things. Moreover, you might have tried to work on this project on different computers. For example, you have a work computer, a home computer, and you understand that this is also not very convenient, right? Thus, programmers quite quickly understand that there is some problem. Moreover, if you want to start working on this project with your friend, how do you do it? Well, you'll give him the files on a flash drive. Well, great, you'll give him these or send them by mail. Well, okay, you sent them. What next? What next? He will have the version of the code at the moment you sent it. You will immediately start editing it. Will you send each corrected line separately or transfer the whole project every 15 minutes to each other? Agree, it's somehow a hassle, difficult, and inconvenient. I'm not even talking about the situation when you have to take the whole project and give it, for example, to a client, and you need to continue working on it to add new features and, in parallel, in the old version, make changes, fix bugs that the client finds. Do you feel that it's somehow becoming too much of a hassle? And I, as a developer who started working when there were no version control systems in widespread use, will tell you, it was a real pain. We all, the entire department, a large number of developers, just suffered greatly from this, making some separate folders on network drives where we put some versions that were not complete, somewhere someone fixed something, broke something, we had to close rights, so much nonsense there was, you can't imagine. And these were tiny projects by modern standards, so tiny. Even now, probably one developer develops a larger project than the project on which we, the entire laboratory of 15 people, worked. That's the story. Thus, in fact, sooner or later, programmers realized that something needed to be done about all this. Well, here's good news: program code is just text. It's a normal text file. My God, it's just text, letters. You don't need to save any additional colors, any tricky formatting, here it's bold, here it's italic, here's something else. All you need is, in fact, text with spaces. Save any program, and it's quite easy to work with. Thus, long before I started working as a programmer, I didn't know about it, but in fact, programmers invented version control systems that do exactly this. Is there a code repository? That's how old version control systems worked, a little more complex, which stores some current version of the code with a note: this is one version, this is another version, and so on. And every programmer who works with this code can pull it to themselves or send their changes there to the repository. This central code repository is called a repository, but more on that later. And this allows, at least, to roll back their changes and merge with the changes of another developer. Merging is called a merge because "split" connects, right? The word "merge" doesn't translate very well into Russian. Therefore, "merge" in programming, almost everything is used, yes, almost everywhere English is used. Yes, I am still Sergey Nemchinsky, and we are still continuing. Java. Java is more than just technology. It's a huge ecosystem providing many opportunities for creating incredible things. Java FXMED offers various events such as quizzes, quests, and practical webinars to deepen knowledge and get a chance to win a super prize. Join our community, register and participate in Java to develop your skills and win valuable prizes. Thus, we can return to understanding how it all works. I initially worked with such centralized code storage systems. It was CVS, then SVN. Yes, they had a lot of different problems. The biggest problem was that this repository was centralized. On the one hand, it's like everything is great. You have a server to which all programmers are connected, and everyone works with it together. But now, news. What if, for example, the programmer does not have internet access at this moment? For example, he is flying from Ukraine to America. Sorry, he can't do anything at all. He has nothing accessible at all. He is simply cut off from life, absolutely. And he cannot even view his previous versions, he cannot do anything. No internet, that's it, sorry. Moreover, or perhaps less, let's say, a rare situation at the moment, for example, the programmer, well, not the programmer, but the centralized server can go down because the administrators messed something up, hackers broke it, or the program is simply failing. For example, a new version of the version control system that the administrators installed doesn't work. So the entire department is dead, and no one can work at all, anywhere, with anything. Git, the brainchild of our beloved Linus Torvalds, we somehow talked about Linus in that video, you can watch it. This is the second system he broke the whole world with. The first was Linux. You know, it's a decentralized code repository. That is, you have a code repository on each computer, a repository on each computer that works with this code, and a centralized repository, but without which all individual computers can also work. Thus, you keep a history of your local changes on your computer and work calmly without being tied to a centralized server. And to the centralized server, you additionally send your changes or pull others' when you need to merge them with others' changes. This is how you work absolutely calmly without any internet connection, without a continuous connection. By the way, there were also such situations, I'll tell you from my own experience, with centralized repositories, there were also problems that a centralized repository might have, for example, through a very thin channel through which it is very difficult to transfer data. And I perfectly remember how we were pulling this data that was on the neighboring computer, but we couldn't just copy it because we could only pull it from the repository. Yes, we were pulling it for a whole day because, well, sorry, the channel was dead, and it was a real hassle. With Git, all this would have happened instantly because we could have managed, in fact, without this terrible work with a centralized repository. So Git is precisely wonderful for this. I, by the way, didn't like it at first, I thought it was an excess, and then I realized how cool it was, and I saw that it captured the world very quickly, almost as quickly as Linux once did. What does it allow you to do? It allows you to do practically anything. For you as a solo programmer, it allows you to store the entire history of your changes. That is, you made these several changes in different files, said, "Oh, this is a general change," and made a commit, that is, saved your changes. About terms, we'll talk a little later. And you want to roll back, you do a checkout to, well, roll back to the version you want, because you have all these commits, you can look through the history and say, "Oh, I want to roll back to this version because it was correct, the one that is needed." Then you can push all the results of your work to the centralized repository so that other developers who work with your code can pull them. To pull is to pull to your local repository from which you can already work, well, and accordingly, merge your changes with others' changes. That's basically everything. The only thing is that there is, of course, a large number of histories with working with branches. This is exactly what I was telling you about when you, for example, gave a certain version to a client and you need to support it, and you need to develop a new version. These are different branches. I won't go into theory right now, but the general meaning, I think, is relatively clear. Git, like other version control systems, allows you to work with the history of your code changes yourself and work with other programmers and their change histories, while avoiding, well, or reducing the risk of code conflicts. What is a conflict in code? For example, you took and changed some method, some line to another. A programmer sitting at a neighboring computer, or not at a neighboring computer, but working with the same code, changed the same line to another. When one of you first pushes it to the repository, then, well, the old line is replaced by a new one, everything is fine, the repository is like that. And when that programmer pushes that line back to the repository, the repository tells him, "Sorry, dude, but this line has already been changed here," and it throws up a merge conflict, that is, "Here are your changes, here are others' changes. Which ones will we save?" And the programmer himself determines which line to save. I know that he might save the wrong line, for example, his own, because he likes it more. In fact, the other programmer's line was needed. But here, sorry, it's the human factor. And from my experience, these resolutions of these merge conflicts, which lines to save and which not to save, this is usually one of the most difficult problems in collaborative development. But on the other hand, if we didn't have version control systems, this problem would be solved simply: whoever is last is the boss. The first programmer pushed something, and the second just overwrote it, and that's it. No one found out about anything, all his changes would simply be lost. With Git or another version control system, we would simply know about it. Now let's talk about, let's go through the key concepts of Git again. The first concept is the repository. As I already said, these are places for storing project files and revision history. The difference between local and remote repositories is also there. Well, in fact, the repository is where both the project files themselves and their change history are stored so that a programmer can roll back to a previous version and see why such a version, what has changed in it line by line, see all this. Yes, well, and accordingly, there is a local repository that is on your computer, and you can work with it without any internet, without connecting to a centralized server. There is a remote centralized repository where you push your changes, and you pull others' changes. The second concept is commits. A commit is like saving all the changes that were made in the entire project at once. The essence of a commit is that it is atomic. That is, you either completely save all these files, or you don't save them at all. That is, for example, if your change goes through 10 files, then it must be saved immediately in a commit, saved. Here, "saved" is not entirely correct. "Saved to the repository," you could say, all these files simultaneously. But if at this moment someone else changed the same file that you changed there, in the same place, then you will have a merge conflict, and the entire commit will not go through. This is the essence. It won't let you commit until you resolve all merge conflicts, that is, conflicts between your changes and another programmer's changes. It looks like this: you finished some piece of work, like, "Oh, I want to commit now," you make a commit, and the repository says, "You have a merge conflict. This file has already been changed." And at this moment, all merge conflicts are thrown at you directly into your code, and it highlights them in red, so to speak, where which lines are. Well, okay, not exactly, but the general meaning is similar. Yes, it shows you where this line is yours, this line is the enemy's, meaning another programmer's. Which line will you choose? It's possible that you'll make a common line out of it. Maybe both lines are needed, just, let's say, you changed one, he changed another, but in fact, both are needed, just one earlier, the other later. Well, you somehow fix this code, save it, and after that, you commit it to the repository. Well, and then these repositories, in fact, using push, are sent to the central repository. Branches. I already said, they are used for working on new features, quite often in a team, to implement, for example, some new functionality in the system. You create a new branch, for example, "this code, and now we will add whistles and bells here." You create a new branch with whistles and bells. And in this new branch, you work, and in the old code, you fix bugs. When the whistles and bells are done, you merge this branch, merge it with the main branch so that these whistles and bells get into the general code. And while we are developing them, they don't interfere with all the other code. A very common use of branches, in fact, there are many different options. When they create a branch for each individual developer, they create a branch for individual teams, for individual versions, and so on. All this depends heavily on the specific corporate policy of your project, your team, your company, and so on, how it will be done. If you work as a solo developer, in most cases, branches are not needed. Although I still advise you to create a stable branch, a branch in which development is ongoing. It's always useful, at least so that if you need to show someone something, you just open the stable branch, like, "Here, everything works." The development branch usually doesn't even compile much, so, in general, there's that. There are questions about this, so what can you show? So that you always have a stable version that you can show, it's useful. And also concepts that I've already started talking about are pull and push. Pull is the process of getting changes from a remote repository. Push is, accordingly, transferring changes from your repository to a remote one. Yes, that is, from a remote repository to your local one, from your local one to your code, these are separate concepts. From your code to your local repository is a commit. From your local repository to a remote one is a push. From a remote repository to your local one is a pull because you are pulling them here. From your local repository to your code is an update. Sorry, many terms, but in fact, nothing super complicated. In fact, how many terms did we take here? Six, seven. Well, they are all understandable. These are simple English words. Well, so get used to it, you'll figure it out. So, how to understand Git? In general, everything I've told you is more than enough to understand how it all works in principle. In all modern IDEs, well, in most, well, in normal modern IDEs, Git support is built-in, and you can use the IDE's own tools to use this Git. Git itself is free. You can use various already installed remote repositories. The most famous is GitHub, probably you've heard of it. In fact, you register there for free, upload to this central repository, and you can later show your future employer what you've created. But there is also a free GitLab, which we use in our company, for example. We, however, don't use the GitLab that is deployed on their infrastructure at gitlab.com, but the GitLab that we deployed locally. There is also Bitbucket, where you can also create a free repository. What's the difference? They differ, in fact, in additional functionality besides Git itself, which Linus Torvalds wrote. All the wrappers, all the rest. And what to use? Yes, in fact, it doesn't matter. You can use one, another, or a third. It's considered the de facto standard to use GitHub. But in fact, if you use GitLab or Bitbucket, no one will be offended. But I, for example, always prefer to use GitLab because, at least, one of the founders is Ukrainian. Well, it's nice, agree. Yes, and their logo is a fox. Although they say it's a Red Panda, but it already looks very much like a fox, so there's no alternative. Next, you can use Git, as I already said, with the help of your IDE, or you can use it with the help of console commands. Git itself is free. You download the program itself, this .exe, using console commands that suspiciously resemble the terms I told you here: commit, update, push, pull. These are the same commands. Well, in general, I think you'll figure out how to use it. There's no rocket science. But if you want to understand in detail, there are separate, huge numbers of videos with details on how to use specific Git, how to pull it, and so on. All this we plan to add to our mentoring for students, a small course on Git, so as to generally explain how to use it in detail. Well, in fact, seriously, I'll tell you honestly, when I first encountered it, I figured it out, well, I don't know, in an hour, probably. Well, really, because everything you need, I've already told you. And how exactly to write commands when you know what you want to get, well, seriously, you are a programmer, you'll figure it out, it's not difficult, really. Well, that's about it. So, please write in the comments how useful this video was for you, because I am very worried. Did I tell you what you need correctly? Well, and write in the comments, in fact, on what topic you would like to see more videos, and don't forget to subscribe to our Ukrainian-language channel and come to my live channel too. I love you. Subscribe, like, and bye-bye. It's too short, and you don't have time to acquire anything but foolish ideas about yourself. So why pay attention to the words of Gene Simmons? Kiss.