48

Here's a common workflow hurdle I encounter often:

master is our "stable" branch

$ git status
# On branch master
nothing to commit (working directory clean)

Create a module on a branch

$ git checkout -b foo
$ echo "hello" > world
$ git add .
$ git commit -m "init commit for foo module"
$ git checkout master
$ git merge foo

Do work on master or other branches

Over the next couple weeks, more code will be committed to master directly and by other branches. The foo branch will go untouched for this time period.

Resume work/make updates on the foo branch

$ git checkout foo

Oh no! foo is massively out of date! I understand why, but I do need foo back in sync.

The question

How do I get the latest contents from the master branch?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
maček
  • 76,434
  • 37
  • 167
  • 198

4 Answers4

60

If you don't need the branch around:

If you've merged foo back to master, "git branch -d foo" to kill the topic branch, and then "checkout -b foo" in the future when you need to hack on it again.

If you do need the branch around:

You can rebase your topic branch against the master branch:

git checkout foo
git rebase master

Or:

git rebase master foo
Adam Vandenberg
  • 19,991
  • 9
  • 54
  • 56
  • Adam, consider the scenario where I need to temporarily "pause" development on the `foo` branch while I make quick changes on a `bugfix` branch. `bugfix` will be merged into `master`, but then it should be sync'd with `foo` afterward, too. Does that make sense? – maček Oct 24 '10 at 23:21
  • In that case I rebase foo against master: "git checkout foo && git rebase origin/master" – Adam Vandenberg Oct 24 '10 at 23:22
  • 1
    Adam, [`rebase`](http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html) is *exactly* what I was looking for; far more appropriate than deleting/recreating the topic branch, too. If you update your answer to "git rebase master", I'll be happy to accept it. (please do not specify `origin/master`, as I'm not dealing with a remote) – maček Oct 25 '10 at 01:20
  • 6
    additional useful tidbit: `git rebase master foo` is equivalent to `git checkout foo && git rebase master` :) – maček Oct 25 '10 at 01:24
  • 4
    This is potentially harmful if you have already published branch `foo` out of your machine. Rebasing it on master will change the sha of the commits contained in the branch, so when you try to push your rebased version of `foo` they won't match what is in the server, and it will tell you that you cannot complete the push because it's not a fast-forward. – giorgiosironi Jan 23 '13 at 11:56
  • 2
    giorgiosironi: Exactly. `git rebase` should always be done **after** committing your changes, but **before** pushing or merging your changes into a public branch. – Teemu Leisti Feb 28 '13 at 14:00
  • This is really nice, but if someone added something to foo in between (like, a team member). Then it doesn't work or you discard their stuff even though you shouldn't. – matanster Sep 14 '13 at 14:38
  • Bumping in hopes someone will offer an answer that everyone agrees is correct. Neatness counts. – Melinda Green Oct 22 '14 at 04:34
20

Rebasing is the process of moving or combining a sequence of commits to a new base commit. Rebasing is most useful and easily visualized in the context of a feature branching workflow. The general process can be visualized as the following:

Git Rebase visual explanation

The example below combines git rebase with git merge to maintain a linear project history. This is a quick and easy way to ensure that your merges will be fast-forwarded.

# Start a new feature
git checkout -b new-feature master
# Edit files
git commit -a -m "Start developing a feature"

In the middle of our feature, we realize there’s a security hole in our project

# Create a hotfix branch based off of master
git checkout -b hotfix master
# Edit files
git commit -a -m "Fix security hole"
# Merge back into master
git checkout master
git merge hotfix
git branch -d hotfix

After merging the hotfix into master, we have a forked project history. Instead of a plain git merge, we’ll integrate the feature branch with a rebase to maintain a linear history:

git checkout new-feature
git rebase master

This moves new-feature to the tip of master, which lets us do a standard fast-forward merge from master:

git checkout master
git merge new-feature

Taken from Atlassian Git Rebase Tutorial

Mauricio Gracia Gutierrez
  • 10,288
  • 6
  • 68
  • 99
2

I use the following to combine changes from two branches (mine and yours) and to synchronize both branches for continued work. This seems to be working. Does anyone see a problem with it?

git checkout mine # make sure I'm on my branch
git commit -a     # commit changes
git push origin mine  
git checkout yours # switch to your branch
git pull origin yours # get changes you've committed & pushed
git checkout mine 
git merge yours # merge your changes into mine
git push origin mine 
git checkout yours 
git rebase mine # set your branch to the merged result
git push origin yours # push the merged result up to your branch on origin
git checkout mine # get back to my branch
user74279
  • 71
  • 3
0

Adam answer is good one.

Additionally, for those who are using IntelliJ and need help regarding rebase and merge, here is a link of youtube video. This will help you to visually understand how rebase works.

https://www.youtube.com/watch?v=Nftif2ynvdA

Muhammad Tariq
  • 3,318
  • 5
  • 38
  • 42