In the past few months, I have spent my free time trying to support new developers to find their first commercial experience.

Usually I find that most of these candidates are not far off from being technically ready, but what they really lack is knowledge of the “ecosystem” that experienced developers passively use without even considering it important.

Today I am going to focus on Version Control. This post is not going to explain you how to use the tool ( there are lots of fantastic videos and courses our there than can do that for you), but is going to focus in explaining individual technical terms that are sometimes hard to understand without the proper explanation or example.

What is Version Control

Formally started in the 70s under the name of Source Code Control System, is one of the most used tool across team of developers. The actual definition of Version Control is:

[quote name=””]Version control systems are a category of software tools that help a software team manage changes to source code over time.* [/quote]

The main task achieved by version control is to orchestrate changes of files within the project. In simple words Version control software allow multiple developers to work on the same project at the same time, all without problem or possibility of overriding everyone else work.

The main reason why this tool is not very common in new developers is probably because it does not seem useful for a single developer, and people underestimate its hidden powers.

Master, Origin and the simple commands

To explain it further we are going to use some real life example to explain some of the technical terms used by developer. The example we are going to use is the one of a cloud storage like Dropbox or Google drive. Many of us use them on  day to day bases, and comparing Version Control to it should help in understanding some of the technical aspects and words used.

Origin

When working on a Project, all developers will have a copy of the project locally on their drive, but ORIGIN is a shared copy that holds all the information and is the true copy of the project. If you take the example of google drive, this will be the folder stored in the cloud, that all users of that google drive account can access from their browsers.

Fetch

This is one of the most simple command in Version Control. This will allow a developer to update all the History of the files. This command does not actually changes any file locally, it is just used to show a developer is something is changed in Origin and inform the developer if the version of the files he is working on are up to date or need to be updated.

Using again the example of Google Drive, this happen every time a computer is switched on when the computed Synchronise with the Cloud folder, to see if anyone has changed any file.

Pull

The fetch command is sometimes omitted by developer, that tent to Update the file locally directly using the “pull” command. Issuing a “pull” command will behind the scene “fetch” all the information from “origin” and then it will download all the required changes on the developer machine to make sure that the project files are up to date. A succesful “pull” will mean that your local project files are the same of ORIGIN

Bringing back our simple example above, the Synchronisation of file is usually followed by this file behind downloaded and updated locally and this is what a “pull” does.

Push

This is the last of the simple and most used command. All the above commands are used to grab information from origin, but “push” is used to update ORIGIN with local changes that we have done to files within the project.

A successful push will mean that your copy of the project and Origin are the same. It is important to note, that after someone “push” the code to origin, all other developer need to “pull” to have an up to date version of the code.

Master, Branches, Merges and Merge Conflict

Now that we have covered the simple commands, it is time to start and move to something a bit more complicated. In this art of the article, we are going to build a car to support our thinking and hopefully help explain this hard commands.

Branches

In small small projects all developers will work on the default Branch called Master. This will be the “only” representation of the project. But it is very common for developers to use Multiple branches within the project. Branches are usually used to develop feature, updates that a developer does not want to be part of master.

Merge

Depending form the outcome of our Branch work, we may need to combine the new feature with the main work “master” or in another “branch”. To do so, we need to use a command called “merge”. We usually merge a branch “into” another. More details will be given below with our example.

Merge Conflict

Unfortunately, not always everything ends well. Sometimes when Merging branches we may end up in conflict. This conflict occur when more than one developer have worked on the same file ( more precisely the same line) and the Version Control Software does not know how to deal with the changes. This situation is quite tricky and we will try to cover it in more details with the example below.

The production Line example

We are the proud owners of a single car production line. This establishment is called “master” in which we build our first version of the car.

We are now going to Experiment on the car to create an update on our current model. We take the finished car (pull from master) and we create a specific “branch” in the factory to add a feature to the car, a dashcam. After this feature has been added in my branch, and the engineer are happy with the change we “merge” our work back in the main production line (master). After doing so, every car will now come with a dashcam.

We are now going to carry two experiment at the same time. As previously done, we are going to get the current model form the production line and we are opening two new branches. Branch1 and Branch2.

In branch one we are going to add a new feature, Automatic mirror, in the other Branch, we are going to work on a separate feature called “dark mirror”.

After some time spent in Branch one, we have decided to merge the work back into the main product line. As with our previous example, there is no issue because no one has worked on any feature on this car that affected the mirror ( or at least not in master).

Development on the second branch has now completed and we want to merge the second branch in master. Unfortunately, when trying to merge this new feature in the main production line, we have a “merge conflict”. There are two parts on the same production line that try to change the mirror. One wants to add automatic mirrors and the other wants to make it black. To solve this issue the engineer need to manually decide which feature he wants to keep between the different branches. In our case the Engineer has decided to keep both and will solve the conflict by adding both feature in the main production line.

 

Conclusion

In the above article I have just touched slightly some of the most used commands and terms that are use when using a version control. Using a Version Control software is like driving a car, initially it seems impossible, and everything is extremely hard, but then it becomes muscle memory and it is straight forward.

Unfortunately for me, this is the case now, and it is extremely hard trying to put even simple task in words. I thought this article would be easy for me, but it turned out to be one of the hardest.

If any of you know how to explain this in better terms or has comment of question please do not hesitate to comment below and I will happily edit the article to make it better.

References

*  Version Control definition from website: https://www.atlassian.com/git/tutorials/what-is-version-control