"Today I'm going to tell you about the two most popular version control programs: SVN and Git."

"SVN works approximately the way I described in the last lesson. Git is a little more complicated, and I plan to discuss it in more detail."

"Can you give me links to the documentation for SVN and Git?"

"Of course, just a second."

http://svnbook.red-bean.com/en/1.7/svn-book.html

https://githowto.com (this is simply a masterpiece)

"So, Git."

"It's a bit more complicated than SVN. With Git, each user has his or her own local repository in addition to the server repository."

"So where do you commit to?"

"Users always commit to their local repository."

"But what about the server repository?"

"To synchronize the local and server repositories, there are special Pull and Push commands.

"There's a reason for this. Sometimes a programmer needs to do a lot of work on his own part, which may involve several hundreds of commits before it can be added to the shared repository."

"To do this in SVN, you would have to start a separate branch, and then merge it with the trunk."

"With Git, you simply always commit to the local repository, and then send all the changes as a batch to the central repository on the server when you're done."

"This method may seem a little excessive when you're only writing a little code. But when your tasks are so big that they stretch across weeks, then you understand that you can't just write that whole time without committing."

"Why can't you just work for two weeks, and then commit your changes to the server once?"

"Well, a version control program offers a lot of conveniences."

"Imagine that you commit every day, and on the 10th day you discover that the changes you made over the last two days won't work as planned. And you want to revert to the code you had on the 8th day and approach the task differently."

"You simply roll back the changes made to the local repository in the last two days and return to the desired state. This is known as a rollback operation."

"You're telling me you can do that?"

"Yep. In addition, because the commit history is stored, you can find out when and why something was committed, and by whom, the relevant features/bugs, and which ten files were simultaneously modified as part of this work."

"Suppose someone's bug fix breaks someone else's code. You can just roll back (rollback) the code and proceed as if the change never happened."

"OK, that's cool. I'm convinced. Could you show me a couple of examples illustrating how all of this works?"

"Sure."

"Here's how you clone the central repository to your local computer:"

Commits and branches - 1

"So, the Checkout operation is no longer needed."

"Yep. And here are examples of Push operations:"

Commits and branches - 2

"And Pull operations:

Commits and branches - 3

"Ah. That more or less makes sense."

"By the way, there's a cool service called GitHub."

"Any programmer can register there and create their own Git repositories. I suggest you get more familiar with it."

"Here are a few useful links:"

https://githowto.com

https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

https://articles.assembla.com/using-git/getting-started/set-up-git-on-windows-with-tortoisegit

"Note that there are quite a few Git clients."

"First, there's  GitBash, which lets you enter text commands."

"Then there's TortoiseGit, which is a good program built into Windows Explorer. It lets you work with files in a Git repository directly in Explorer."

"IntelliJ IDEA supports Git and lets you execute all sorts of complex commands with just a couple of clicks directly from within the environment."

"So, which one should I learn?"

"I recommend that you get to know all of them."

"You'll pass your interview and arrive at work. You'll get a link to Git, a login and password — and that's it. Then you're on your own."

"What do you mean, «on your own»?"

"I mean you'll set up Git by yourself, pull a copy of the repository by yourself,…"

"And then you'll need to build and try to run the project."

"The build instructions will also most likely be in the Git repository, along with the project documentation."

"Your team lead will come up to you in the evening and say, «Well, what have you figured out so far?»"

"And you'll say, 'I'm trying to set up Git here, but haven't had any success yet. «You aren't going to fire me, right?»"

"Or, while it's still midday, you can go to the team lead and say, «I installed Git, pulled the project, and browsed through the documentation, but there are hundreds of files and I haven't sorted everything out yet. Where are the current build instructions?'»"

"Can you feel the difference?"

"Yes. In the second case, I'm a super rock-star programmer, but in the first, I'm some robo-doofus who doesn't even know how to pull a project from Git. In other words, I screwed up before I even got to start programming. I suppose that after that they wouldn't even let me write code."

"See, you answered your own questions. So study and figure it out. Nobody will do it for you."

"You aren't going to help me?"

"I've already helped. We're teaching Java here, in case you've forgotten. For everything else, you're on your own. Or is your head just for drinking?"

"Okay, I get it. Thank you, Bilaabo!"