In the previous post, I gave a working definition of branching (based on Git’s model of source control) and provided a conceptual model that I hope makes it easier to understand what’s happening whenever you branch code from the
master branch of the application.
The thing about creating branches is that they’re typically merged back into the main application once a feature has been completed, a bug has been resolved, or something has been patched.
If branching is taking a copy of the code and creating an independent sandbox out of which to work on the program, then merging is the opposite – it’s taking the code from the branch and pushing it back into the main part of the application.
A Guide To Merging
As previously mentioned, the whole idea behind these two posts is to provide a beginner-level perspective on how branching and merging work within the context of source control (using Git’s model as our base).
Branching and merging are not unique to Git, but a lot of developers tend to be using that particular version of source control right now, so it seemed to make the most sense to use it as the core example.
Anyway, according to the Git definition, merging is defined as the following:
Incorporates changes from the named commits (since the time their histories diverged from the current branch) into the current branch. This command is used by git pull to incorporate changes from another repository and can be used by hand to merge changes from one branch into another.
But another, simpler way to look at it (much like we’ve already discussed at the beginning of the post), is like this:
Take the code from the current branch off of which you’re working and place it into the
masterbranch so that the new code is part of the core application
So if you have an application with two branches similar to the image below:
Then merging the two branches back into the
master branch would look something like this:
The thing is, there can be some complicated things that come up with merging, and though this post is not the one that’s meant to walk through how to resolve them, it is worth mentioning that one of the things that you’re most likely to experience when performing a merge is a merge conflict.
What’s a Merge Conflict?
Essentially, a merge conflict is when you have, say, two versions of a file – one from
master and one from your own branch – and the source control application can’t figure out how to best merge the two files together into one.
In order to overcome this, it’s up to you to use a tool such as Kaleidoscope in order to manually merge the two files together. This, in essence, creates a third version of the file (the
master version, the branched version, and the merged version) that will be placed into the
master branch once the merge is complete.
Of course, it’s up to you to figure out exactly how to properly merge the file (that is, which line gets merged?) but that’s the topic for a more advanced post.
At any rate, this should cover the basics of branching and merging and hopefully this helps to make a little bit easier to understand why branching is useful and how merging works.