Git good… Merging for beginners

One of the highlights of Git is the way it manages branching. Compared to other Version Control Systems (VCS), Git branching is easier and more efficient. At the core of it, branching offers the ability to develop a new piece of code without affecting the main source code or the code in other branches. People can work on several ideas or features simultaneously without worrying about the changes others are making. You can also go back and forth in the development tree, pick a particular version of the code to either deploy on production or to modify it. Let us look at a scenario where a developer would have to create multiple branches and update the master with both changes.

Imagine you are developing a new feature for a software product. Generally, there will be a master branch, which is deployed to production, and you would create a branch and work on developing the new feature. Now say that your colleague discovered a bug in production which needs to be fixed immediately. Would you wait till the feature is developed and deployed before fixing the bug? Would you want to pause or discard the development of the feature till you fix the bug? Which of the two takes precedence? Probably a better approach would be to develop the feature and the fix independently and deploy them whenever they are ready. You can merge the other branch at a later point in time. Branching enables this. Let us take a closer look at this example.

Imagine that the source code of the product is in a single master branch, with two commits. You create branch_1 and start developing the feature. At the same time, your colleague can work on the bug fix by creating the branch fix_1 from master. He/she does not have to worry about what you are working on, the files you are altering, changes you are making or when you plan to include the feature in the product. Either your colleague or you can complete development earlier and can merge it with the master branch without any worry. Now the master is pointing to a new commit.

The person trying to merge later needs to be more careful because there has been a divergence in the development history, i.e., the current master is different from the master from which the branch_1 was created. Git considers the “original” master (which was the parent of branch_1), current master (your colleague’s new commit) and the branch_1 (your final commit). Git checks if there I any conflict between the branches, i.e., checks if common parts of common files were changed differently in branch_1 and fix_1. If there are no conflicts, Git merges the two branches, creates a new commit and updates master. This new commit is called a merge commit, and it references both branches as parents.

What would happen if there was a merge conflict between the changes in branch_1 and fix_1? Git would not proceed with the merge, and it is up to the developer to resolve this conflict. You can either select one of the two variants of the code or write a new code that can implement both changes as desired. Once you resolve the conflict, you can continue with the merge as before. Git enables developers to collaborate efficiently. They can work on pieces of software independently and bring them together to build products.

Gitstorage is the perfect device for people developing new software or considering alternatives to cloud git repositories.

Like what you read? Give Steve Davis a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.