Table of Contents
This post will answer all your questions about what version control is and why do we use version control and what are its features.
Version Control Explanation
It is very common these days that many developers want to have full control over their generated code while developing. Sometimes we work on a small chunk of code and sometimes it’s a very big feature, we always don’t remember what was the function of the code we did. We might have written the code while we were half asleep, in the early morning, or Drunk … Who can tell !!
Why we use Version Control ?
So, Controlling our source code is a must. If you think that the “undo” shortcut in your favorite editor has saved your life countless times then, imagine having an “undo” for your entire project for every change you have made. Imagine you have a directory made for editing each of your project files line by line.
There are many kinds of version control that we are using these days: GIT, SVN, Mercurial, etc.
Some of The Features Using Version Controls are :
Branches
The current version you working on is called a “HEAD”. In a project, we have many heads so the project has several BRANCHES. A branch is just a copy of the project with new changes you are making to it. Each branch can be evolved and edited independently.
Imagine that we have a production version that is in the air and is live. It is very important to preserve this production version and anyone can not make changes to this. But we need another room so that new features can evolve, fix bugs can be made, etc… But without affecting the main production branch. Here is when branches play a very crucial role.
Versioning
Versioning is one of the base features of code control. When started to work as a to the developer, for making a backup in my project I used to create multiple directories and folders myProject-v1 , myProject-v2 etc … These folder kept Big changes I did for Development. It is very likely to happen that if you lose any version of the project that what change you have done, you can not remember all the small changes and modifications you have made and that is a big problem.
Whenever a developer finishes a task, a commit is made which in turn creates a reference point, and a version of all those files is created. Similarly, every commits creates a version of your code. One more amazing thing is that if something goes wrong in any of the functionality you can find out the exact point where the problem has occurred.
Logs
Whenever a developer makes a commit there is a message added to that commit so that whatever code is committed has a small tag line that what this code was created or modified for. This creates full logs of our commits.
Diffs
Diffs are amazing. For instance, you want to compare two versions of the same file to find out which line of code was modified. You can do a difference between versions of the file which will allow you to find that was exactly where the errors present when using the logs, we know the exact reason why the person included that line of code, and who made those changes.
Rollback
Because we have a history of all the commits, we get to go any place in that history, which means we can go back to any change we made. And this happens within seconds. This is one of the best things with our version control.
Multiuser editing and Merge
This is a cool one. I know sometimes the entire team loses a file because two developers opened the same file for editing from the live server. So Because of this, a team is not able to do multitasking. But using Version Control anyone can make changes at any time.
Also, version control compares the changes made to the file by the developers and joins those codes automatically. Which is extraordinary.
What are Conflicts ? and How to Solve Conflicts ?
And when the developers modify the same file on the same line of code? Version Control creates a conflict, this conflict should be resolved by the developer who made the changes in last for that file.
It is how it all works:
1. Two developers open the same file and made changes to the same line of code.
2. When their work is completed, they generate a commit. If developers might have made edits in different lines of the file, for instance, one at the ending of the file and the other at very binging, the Version Control joins both the codes doing a merge and create one updated file with both two revisions.
3. If the system sees that the developers have made changes in the same line (In Our Case), the system generates a conflict, because the system does not know which of the two codes are to be kept or are correct.
4. The conflict is resolved by the developer to commit the code last. So when you commit your code, it is important to download what is on the server then the version control will tell you which file and what line has got a conflict.
The conflict is resolved to show something like this:
span {
<<<<<< HEAD : Custom.css
background-color : blue;
========
background-color : green;
>>>>>> 779a35dat4a11db4580b802327e8d65caf5208086 : Custom.css
}The first line shows your code and modifications. The second line shows the other developer’s modification and code. The hash code at the end is the identification of the commit done by the other developer.
Now you need to check what code is correct and remove the other code and commit it again.
That’s it.