Isolating features into different branches is a crucial practice for any serious developer. By separating each feature, bugfix or working experiment you will avoid a lot of problems and keep your development branches clean.
At some point, a piece of code will reach a state where you'll want to integrate it with the rest of the project. This is where the git merge command comes in.
Preparing to Merge
Let's assume that you want to merge branch hotfix into your master branch.
Before you start, how to make sure that you are ready to merge your changes?
- Check if your local repository is up to date with the latest changes from your remote server with a
git fetch. - Once the fetch is completed
git checkout master. - Ensure the master branch has the latest updates by executing
git pull. - Checkout to the branch that should receive the changes, in our case that is master.
Merging
Once the preparations are completed, you can start the merge with git merge hotfix command.
Fast Forward Merge
A fast-forward merge can occur when there is a linear path between branches that you want to merge. If a master has not diverged, instead of creating a new commit, it will just point master to the latest commit of the hotfix branch. All commits from hotfix branch are now available in master.
However, a fast-forward merge is not possible if the branches have diverged. In this case, you want to use a Three-way merge.
Three-Way Merge
When there is not a linear path to the target branch, Git has no choice but to combine them via a three-way merge. This merge uses an extra commit to tie together the two branches.
Test this out! Create your own project with an RSpec test branch and at the same time edit the Controller tests in master. Now, try to merge.
How to Deal With Merge Conflicts
A merge conflict occurs when two branches you're trying to merge both changed the same part of the same file, Git won't be able to figure out which version to use.
For example, if the file example.rb was edited on the same lines in different branches of the same Git repository or if the file was deleted, you will get a merge conflict error when you try to merge these branches. Before you can continue, the merge conflict has to be resolved with a new commit.
Merge conflicts will only occur in the event of a 3-way merge.
-
Generate a list of the files which need to be resolved:
git status
# On branch master
# You have unmerged paths.
# (fix conflicts and run "git commit")
# Unmerged paths:
# (use "git add ..." to mark resolution)
# both modified: example.rb
# no changes added to commit (use "git add" and/or "git commit -a")
- When the conflicted line is encountered, Git will edit the content of the affected files with visual indicators that mark both sides of the conflicting content. These visual markers are:
-
<<<<<<<- Conflict marker, the conflict starts after this line. -
=======- Divides your changes from the changes in the other branch. -
>>>>>>>- End of the conflicted lines.
-
<<<<<<< HEAD(master)
conflicted text from HEAD(master)
=======
conflicted text from hotfix
>>>>>>> hotfix
- Decide if you want to keep only your hotfix or master changes, or write a completely new code. Delete the conflict markers before merging your changes.
- When you're ready to merge, all you have to do is run
git addcommand on the conflicted files to tell Git they're resolved. - Commit your changes with
git committo generate the merge commit.
Hope this helped you get a better understanding how to merge your branches and deal with conflicts.
This article is originally published on Kolosek Blog.
Top comments (16)
If you like keeping a cleaner history you can rebase the branch onto master prior to doing the merge. It depends on how vital the independent branch history is.
If you don't do a rebase it often makes sense to merge master into the branch first. This allows you to resolve and test conflicts, get a stable state, then have a flawless merge to master. Logically it sounds about the same, but in some pipelines it works better.
I always prefer rebasing the feature branch first, then merging. It allows for a simpler linear repo history (this is if I'm the only one working on it).
I also like to clean it up with some commit squashing with:
git rebase -i HEAD~n.Couldn't agree with you more!
In the future, there will be another article regarding rebasing that will cover its positive and negative points compared to merging.
Actually, I do not agree. There might be cases were this strategy is useful. My team tried both, committing to master/dev as well as using feature branches for every feature.
We agreed to stop using feature branches because it added complexity and large efforts due to merging without giving us benefits. We never needed to skip features that are not complete. We never needed to reject features. However we had serious troubles merging code after refactorings e.g.
Moreover, we had a contionous job that builds, deploys and runs a system test against code changes for immediate feedback.
So, in some scenarios feature branching might be useful but definitely not in all.
Hey, Jan, I understand your point, merging can cause some frustration, especially when conflicts happen.
Kolosek team prefers to create a new branch for each feature unless it is a hotfix or emergency bug fix. In this case, we commit directly to master or development.
To ensure the code is "clean" we always have someone to check the Pull Request before merging the feature branches. This is another reason why we mostly go with feature branches.
This is exactly opposite the latest findings of highly effective teams, there is a correlation of highly effective teams and trunk based development or branches with a lifespan of less than a day. See "Accelerate: Building and Scaling High Performing Technology Organizations", it bases its data off of statistics that I imagine any one of us will be hard pressed to argue against effectively.
The point is to get changes in as soon as possible, not features, but changes. I try to only work in branches when I need a merge-request reviewed (e.g. if I couldn't pair on the change). BTW low-overhead change-management process is another correlation of effectiveness. And if talk of correlations bore you I'll just say it's a lot more fun to develop without all those processes :)
(and thanks for sharing your article and viewpoint, it's by discussion we grow)
Hey, Jon! Well, currently, our team prefers to separate each specific feature into a separate branch, since multiple people work on different features at the same time.
That being said, when it comes to hotfixes or any crucial bugs that need immediate and quick attention we push those changes directly without creating a new branch for each problem.
Sure, my pleasure, that's why this is a great community. We share opinions and grow. :)
I can relate to that from my(limited) experience. Together with CI, pushing to master as soon as possible has worked quite well.
Thank you for the explanation on the 3-way merge. It cleared up a lot of issues I was having.
Sure, glad you found it helpful!
In the 'After Merge' part of the 'Three-Way Merge' pic in your article, shouldn't C2 and C4 be swapped?
C4 would be the new commit that master points to after merging/combining the C2 and C3 branch. Yet it shows C2 as the latest commit after the merge.
I'm curious, is there any draw backs with merging the master branch into the hot fix branch. Then running regression tests on the hot fix branch and then merging the hot fix branch into the master branch.
This is really really useful. I only use Git from the command line interface, that's why I want to understand the core concept of Git so everything can be smooth and productive.
Thanks for posting.
Nice post! always good to git fetch git pull then git merge origin/dev :)
Glad you liked it, Tony! :)
Thanks for the explanation on the 3-way!