This Post will answer all your question about what a version control is and why do we use a version control and what are its features .
Version Control Explanation
It is very common these day that many developer want to have full control over their generated code while development . Some time we work on small chunk of code and some time its 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 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” short cut in your favorite editor have 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 kind of version control that we are using these days : GIT, SVN, Mercurial etc.
Some of The Features Using Version Controls are :
The current version you working on is called a “HEAD” . In a project we have many heads so 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 production version that is in the air and is live . It is very important to preserver this production version and any one can not make changes in 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 is one of the base features of the code control. When stared to work as a to developer, for making 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 some task, a commit is made which in turn creates a reference point, and a version of all those files is created. Similarly every commits to 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 .
When ever a developer makes a commit there is a message added to that commit so that what ever code is commit has a small tag line that what this code was created or modified for . This create a full logs of our commits
Diffs are amazing. For instance you want to compare two versions of the same file to find out which lien of code was modified . You can do a difference between versions of the file which will allow you to find that where exactly where the errors present, when using with the logs, we know exact reason why the person included that line of code, and who made that changes.
Because we have a history of all the commits, we get to go any place in that history, Means we can go back to any change we made . And this happens within seconds . This is the 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 any one can make changes 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 change on 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 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 change 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 showing something like this:
<<<<<< 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 developers modification and code. The hash code at the end is the identification of commit done by the other developer.
Now you need to check what code is correct and remove the other code and commit it again .
Thats it .
Well I use GIT as my Version Control. So if you want to learn about Basic Commands Used in Git Click Here