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 master and... here is my problem:
How do I update all other branches with master branch code?
You have two options:
The first is a merge, but this creates an extra commit for the merge.
Checkout each branch:
git checkout b1 Then merge:
git merge origin/master Then push:
git push origin b1 Alternatively, you can do a rebase:
git fetch git rebase origin/master 
got push origin master... doesn't make sense. You're not changing master branch. I think it's a mistake with 119 upvote :/
git rebase master is the correct answer
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.
git can 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 merges master, or master merges 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 E', F', and 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 master are important to the development in b1.
The consequence of this may be, that you can't distinguish which of the three commits E, F, and G actually introduced a regression, diminishing the value of git bisect.
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.
git checkout <source branch> git pull. Then continuing with above: git checkout b1 ...
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.
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 Notes:
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 checkout local_branch_name could be git checkout - if the branch you were previouly on was local_branch_name@cmaster made the best elaborated answer. In brief:
git checkout master # git pull # update local master from remote master git checkout <your_branch> git merge master # solve merge conflicts if you have` You should not rewrite branch history instead keep them in actual state for future references. While merging to master, it creates one extra commit but that is cheap. Commits does not cost.
Surprisingly the most common method I use isn't mentioned. It's quite common when working Trunk Based Development style where master constantly gets updated and one is working from a branch from it.
Let's say master already has the updated code and that you are in branch b1. If that's not the case, you'll need git fetch.
So, to update b1 with the changes made in master, you can simply pull the code using
git pull origin master The same will have to be done in the other branches when you, or someone else, gets to them and wants to update as well.
rebase or a merge mentioned in other answers?To update other branches like (backup) with your master branch copy. You can do follow either way (rebase or merge)...
Merge branches (there will be an extra commit automatically to the backup branch).
Note : Rebase is nothing but establishing a new base (a new copy)
git checkout backup git merge master git push
(Repeat for other branches if any like backup2 & etc..,)
git checkout backup git rebase master git push
(Repeat for other branches if any like backup2 & etc..,)
to update your branch from the master:
git checkout master git pull git checkout your_branch git merge master 
git pull --ff-only to avoid unwanted side effects.You can merge, or you can apply individual commits across branches by using git cherry-pick.
You need to do a forceful push after rebasing against master
There are two approaches
You want to merge the master branch into your branch
- git checkout master - git pull - git checkout your-feature-branch - git merge master //resolve conflicts if any and commit - git push 2: If you want to rebase your changes on top of main.
git checkout master #Switch to main branch git pull #Take latest git checkout your-feature-branch #Switch to story branch git pull --ff-only # Ensure branch is up to date git rebase -i origin master #Interactively rebase your commits on top of master. So your changes are on top of latest commits in main. git rebase --continue #Resolve conflicts and rebase --continue to continue with next commits git push -f origin your-feature-branch # As you have rewritten the commit history, you have to **force push** the commits 
For everyone who finds this thread searching for an easy-to-use and consistent solution to merge your current branch with the latest changes on master:
You can add this to your shell configuration:
alias merge='currentBranch=$(git rev-parse --abbrev-ref HEAD) && git checkout master && git pull && git checkout $currentBranch && git merge master' This alias works with 5 commands:
currentBranch=$(git rev-parse --abbrev-ref HEAD) # gets your current branch(needed for point 4) git checkout master # checks out master git pull # gets latest changes from master git checkout $currentBranch # checks out the in point 1 saved branch git merge master # merges your current branch with master After adding the alias, you can simply use the command “merge” to “update” the branch you are currently working on.
IN CASE IF YOU WANT TO REVERT TO A LAST COMMIT AND REMOVE THE LOG HISTORY AS WELL
Use below command lets say you want to go to previous commit which has commitID SHA - 71e2e57458bde883a37b332035f784c6653ec509 the you can point to this commit it will not display any log message after this commit and all history will be erased after that.
git push origin +71e2e57458bde883a37b332035f784c6653ec509^:master There are two options for this problem.
1) git rebase
2) git merge
Only diff with above both in case of merge, will have extra commit in history
1) git checkout branch(b1,b2,b3)
2) git rebase origin/master (In case of conflicts resolve locally by doing git rebase --continue)
3) git push
Alternatively, git merge option is similar fashion
1) git checkout "your_branch"(b1,b2,b3)
2) git merge master
3) git push
