Version control systems

"Hi, Amigo!"

"Hi!"

"Today I will tell you about version control systems."

"As you probably already know, programs are often very large and take a very long time to write. Sometimes dozens of people can spend years writing a program."

"Projects with millions of lines of code are a reality."

"Whoa."

"It's all very complicated. People often interfere with each other, and often modify the same code, and so on and so forth."

"To bring order to this mess, programmers began using version control systems for their code."

"A version control system is a program consisting of a client and server.

"The program stores data (the code written by programmers) on a server, and programmers add to or change it using clients."

"The main difference between a version control system and programs that simply make it possible to work collaboratively on documents is that it stores all of the previous versions of all the documents (code files)."

"Can you give me more details. How does it all work?"

"Imagine that you are a programmer and you want to make small changes to the source code of a program stored in a repository on the server."

"Here's what you need to do:"

"1) Log in to the server."

"2) Copy the latest version of all of the files to your computer using the Checkout command."

"3) Make changes to the required files."

"4) Run the program locally to make sure that it compiles and runs."

"5) Send your 'changes' to the server using the Commit command."

"That generally makes sense."

"But there's more. Imagine that you arrive at work in the morning, but it's already lunchtime in India. So your Indian colleagues have already made changes and committed their changes to your repository on the server."

"You need to work with the latest version of the code. So you perform the Update command."

"How is that different from Checkout?"

"Checkout is designed to copy all of the repository's files, but Update only updates the files that have been updated on the server since you last ran a Checkout/Update command."

"This is approximately how it works:"

Checkout:

"Now, let's say we changed file B and want to upload it to the server. To do this, we need to use the Commit command."

"And here's how the Update command works:"

"How interesting! Are there any other commands?"

"Yes, there are quite a few. But they vary depending on which version control program you choose. So, I'm trying to just explain the general principles."

"There is also an operation called merging—the union of two documents. Suppose two programmers are modified the same file at the same time. Then the program on the server will not allow both changes to be committed. Whoever commits first gets to add his or her changes."

"So what does the other person do?"

"He or she will be invited to perform a Update operation to grab the latest changes from the server. By the way, this — doing an Update before committing — is good practice."

"Then, during the Update operation, the client program will try to merge the local changes with the changes received from the server."

"If the programmers changed different parts of the file, then the version control program will probably be able to merge them successfully. If the changes are in the same place, then the version control program will report a merge conflict and prompt the user to manually merge the changes."

"For example, this often happens when both programmers add something to the end of a file."

"I see. Overall, that seems reasonable."

"And there's one more thing: branches."

"Imagine that two programmers from a team are tasked with rewriting the same module. Or even better — rewriting it from scratch. Until this module is completed, the program won't be able to run, and might not even compile."

"So what are they supposed to do?"

"They move forward by adding branches to the repository. Roughly speaking, this means the repository gets divided into two parts. Not by files or directories, but by versions."

"Imagine electricity was never discovered and robots were never invented. Then the three liberation wars would never have happened, and all of human history would have followed a completely different path."

"This path is an alternative branch of history."

"Or you can just try picturing a branch as simply a copy of the repository. In other words, at some point, we made a clone of the repository on the server, so that, in addition to the main repository (often called the trunk), we have another branch."

"Well, that seems more understandable.

"Why couldn't you just say that we copied the repository?"

"This isn't simple copying."

"These branches can not only be separated from the trunk, but also merged into it."

"In other words, some work can be done in a branch, and then when it's finished you can add the repository branch to the repository trunk?"

"Yep."

"And what will happen to the files?"

"The files will be merged."

"Well, that sounds cool. I hope it's just as cool in action."

"And then some. Okay, let's take a break."

"There is a bunch of useful information here"