1

I have two branches, master and my-work-branch

Other people will push changes to master, so I need to keep my-work-branch synced with master so that I also get other people`s changes

I tried to rebase from my-work-branch against master branch often with the following command 

git rebase origin/master

I did that two days ago, so git log in my-work-branch is something like this:

merge change from master
my change a
my change b
my change c
...
latest change from master two days ago

Today I ran the same rebase command again, (during the two days, I do not have any changes on my-work-branch, all I do is try to get new changes from master)

However, I noticed that git applies my changes (a, b, c ... ) twice (I can see it in the git log), and also it caused conflicts, so I need to resolve the conflicts.

Does anyone know why this would happen? Is git rebase the wrong way to keep my-work-branch in sync with master branch?

Dalija Prasnikar
  • 27,212
  • 44
  • 82
  • 159
jojo
  • 13,583
  • 35
  • 90
  • 123
  • I think you want git pull instead of git rebase – Jonathan Jan 20 '15 at 19:55
  • @Jonathan, git pull will pull from my remote branch, do you mean i specify the origin to pull from master? – jojo Jan 20 '15 at 20:29
  • http://stackoverflow.com/questions/20101994/git-pull-from-master-into-the-development-branch – Jonathan Jan 20 '15 at 20:31
  • @Jonathan, i saw that, but that merge changes base on time line. but i think i got it now. i should do "git pull --rebase origin master", then it will bring my change on top of change from master – jojo Jan 20 '15 at 20:42

1 Answers1

0

Git rebase is perfectly OK to keep branches in sync, in fact some people (like me) prefer it over the push/merge technique as the way to keep more straight history. But you have to get used to this command.

I assume you regularly do git fetch to keep your origin/master in sync with the other people's changes.

It is normal to get conflicts on repeated rebases in such case because there could have been new changes upstream (origin/master) that have caused it.

I am not sure why do you see same commits twice, maybe because you are in incomplete rebase?

In order to check what is happening, you could git rebase abort to restore the state before you started the rebase, and do git rebase -i origin/master - it would show you the commits picked to be put on top of the origin/master. If there is more than you expect - something is wrong with your branch state.

You may also use combination of git log <my branch> --not origin/master and git log origin/master --not <my branch> to easily see commits that are present upstream but not in your branch and vice versa.

Mykola Gurov
  • 8,517
  • 4
  • 29
  • 27