The best answers to the question “Update Git branches from master” in the category Dev.
I’m new to Git, and now I’m in this situation:
- I have four branches (master, b1, b2, and b3).
- After I worked on b1-b3, I realized I have something to change on branch master that should be in all other branches.
- I changed what I needed in
masterand… here is my problem:
How do I update all other branches with
master branch code?
You have basically two options:
You merge. That is actually quite simple, and a perfectly local operation:
git checkout b1 git merge master # repeat for b2 and b3
This leaves the history exactly as it happened: You forked from master, you made changes to all branches, and finally you incorporated the changes from master into all three branches.
gitcan handle this situation really well, it is designed for merges happening in all directions, at the same time. You can trust it be able to get all threads together correctly. It simply does not care whether branch
b1, the merge commit looks all the same to git. The only difference is, which branch ends up pointing to this merge commit.
You rebase. People with an SVN, or similar background find this more intuitive. The commands are analogue to the merge case:
git checkout b1 git rebase master # repeat for b2 and b3
People like this approach because it retains a linear history in all branches. However, this linear history is a lie, and you should be aware that it is. Consider this commit graph:
A --- B --- C --- D <-- master \ \-- E --- F --- G <-- b1
The merge results in the true history:
A --- B --- C --- D <-- master \ \ \-- E --- F --- G +-- H <-- b1
The rebase, however, gives you this history:
A --- B --- C --- D <-- master \ \-- E' --- F' --- G' <-- b1
The point is, that the commits
G'never truly existed, and have likely never been tested. They may not even compile. It is actually quite easy to create nonsensical commits via a rebase, especially when the changes in
masterare important to the development in
The consequence of this may be, that you can’t distinguish which of the three commits
Gactually introduced a regression, diminishing the value of
I am not saying that you shouldn’t use
git rebase. It has its uses. But whenever you do use it, you need to be aware of the fact that you are lying about history. And you should at least compile test the new commits.
You have two options:
The first is a merge, but this creates an extra commit for the merge.
Checkout each branch:
git checkout b1
git merge origin/master
git push origin b1
Alternatively, you can do a rebase:
git fetch git rebase origin/master
If you’ve been working on a branch on-and-off, or lots has happened in other branches while you’ve been working on something, it’s best to rebase your branch onto master. This keeps the history tidy and makes things a lot easier to follow.
git checkout master git pull git checkout local_branch_name git rebase master git push --force # force required if you've already pushed
- Don’t rebase branches that you’ve collaborated with others on.
- You should rebase on the branch to which you will be merging which may not always be master.
There’s a chapter on rebasing at http://git-scm.com/book/ch3-6.html, and loads of other resources out there on the web.
git rebase master is the proper way to do this. Merging would mean a commit would be created for the merge, while rebasing would not.