0

I'm quite new at GIT but I understood the basics pretty well. However, I'm feeling confused...

We're using github, and my branch was 13 ahead and 20 behind the master branch (so quite out of date).

I did the following:

git checkout myBranch  
git rebase master

I seem to have merged the same files repeatedly for some reason.

I guess it's because I am applying my changes to each of different versions that were commited on the master branch?

This took quite a while, and when I was finished I assumed I could then just push my (now hopefully up to date) branch back to github. But it tells me I have non fast forward changes - which I don't understand...

So then I do a pull, and git tells me I have to merge all the same files again...

I must be missing something fundamental in my understanding of what's happening here.

ANeves thinks SE is evil
  • 5,681
  • 3
  • 35
  • 60
iKode
  • 8,501
  • 13
  • 49
  • 76

1 Answers1

2

Essentially rebase temporarily removes your commits, stores them as patches, gets the head of the master and then reapplies your patches.

Here is a website that explains what git rebase is succulently - http://book.git-scm.com/4_rebasing.html .

BE CAREFUL: Here be dragons! http://vectorya.com/freevectors/vector-cartoons/dragon-baby-green/

If you are absolutely certain there will be no issues, you can ignore the error and perform git push --force. HOWEVER, you risk breaking the central repository. Not advised by Github - http://help.github.com/remotes/ Look for the section Dealing with “non-fast-forward” errors

Or to try and resolve first pull and then push - git pull origin master then git push origin master

One option would be to use git merge instead of rebase. git pull origin master to get the master up to date. There have been debates in the community on rebase vs merge and each have their pros and cons.

To prevent duplicating the content, the articles covering the same topic - http://softwareswirl.blogspot.com/2009/04/truce-in-merge-vs-rebase-war.html, Git workflow and rebase vs merge questions and http://www.randyfay.com/node/89.

Examples of merging into master:

  • git checkout master and then git merge mybranch

To merge master into mybranch and then merge into master

  • git checkout mybranch and then git merge master
  • git checkout master and then git merge mybranch
Community
  • 1
  • 1
First Zero
  • 18,964
  • 6
  • 42
  • 44
  • You are right, added in the consequence and help from github page – First Zero Jan 09 '12 at 12:57
  • @First Zero - Thanks for the answer, I was had seen your first rebasing link before, and on that page it says that you should rebase should you want to keep your commit history. I have read in a few other places that rebasing is better than merging for this reason? – iKode Jan 09 '12 at 15:14
  • @iKode Good point.. This has been a particularly hot topic, Rebase vs Merge. Personally, I have gone with merge to see where branch merging into master, so that I can visually see the merges and avoided rebasing. There have been several articles on this cf - cf - http://softwareswirl.blogspot.com/2009/04/truce-in-merge-vs-rebase-war.html, in StackOverflow - cf - http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions and finally, cf - http://www.randyfay.com/node/89 – First Zero Jan 09 '12 at 16:10