0

I'm busting my head trying to figure what is the right way to work with GIT. I thought I figured it, but lately we had some problems. Here is my situration, really hope I get a simple solution for my problem.

2 persons (call them A & B) working on the same project.

A is doing less development, but he is incharge on reviewing B and push code to production.

B doing most of the development, but cannot push to production, need A to review and approve his code.

Until now we worked like this:

A is working on 'master'.

B is working on branch 'dev' - dev is a remote branch, B is pushing changes to it, A can pull from the remote branch.

A is making changes directly on 'master' (which are pushed to production). When B is done with a feature, A is merging 'dev' to the master (git checkout dev; git pull; git checkout master; git merge dev)

B is working only on 'dev' and tell A when to merge. If A made a change on master, B is rebasing (git checkout master; git pull; git rebase dev; git checkout dev)

This seem to work fine (and we assume it's a correct way to work), but somehow, even after A merged, and B rebased, 'dev' was not equal to 'master'.

What are we doing wrong, is there a different method/workflow we should use for our needs?

  • Note: 'dev' must be remote branch, because sometimes A helps B with problems and 'dev' is also pushed to online test server so other people can test.
phpjohn
  • 3
  • 2
  • I have no time for a full answer, unfortunately, but I suggest you to read this chapter, better even with starting at the very beginning: http://think-like-a-git.net/sections/rebase-from-the-ground-up.html – Boldewyn Nov 18 '11 at 09:24
  • Is A pulling directly from B's respository, or does B push to a central repository which A then pulls from? There could be a number of reasons why the situation you describe could happen, but you haven't given enough detail about the commands you're running to be able to tell. For example, when you say "git merge dev - after pull", does that mean `git checkout dev; git pull origin dev; git checkout master; git merge dev`? What about "git rebase master - after pull"? The branch that you're on when running these commands is very important. – Mark Longair Nov 18 '11 at 09:28
  • Mark, I updated the text with the full commands we use (pretty similar to what you wrote). A base is master B base is dev – phpjohn Nov 18 '11 at 09:38
  • A rebase results in a different revision, often with different content. That's what it is _for_ – sehe Nov 18 '11 at 10:32
  • Rebasing with remote branches is rarely a good idea since you discard history. However, if you really want to do that (only 2 users that know exactly what they're doing), you can follow the recommendations given [here](http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions). – BenC Nov 18 '11 at 12:20
  • Thanks @BenC , Looks like that thread answered my questions exactly and it got the right workflow for us. – phpjohn Nov 18 '11 at 12:40
  • @phpjohn : You're welcome ;-) – BenC Nov 18 '11 at 12:49

1 Answers1

1

I think you're misunderstanding how git rebase should be used. You say that when B wants to rebase his / her work onto master, that developer does:

git checkout master
git pull
git rebase dev
git checkout dev

When you run git rebase dev while on master, that's saying (roughly) to take all the commits that are in master but which aren't in dev, and try to reapply any of those that introduce novel changes on top of master. You probably want to do the following instead:

git checkout master
git pull
git checkout dev
git rebase master

... so that anything new in dev is reapplied on top of master. Note that after these commands, you would only expect dev and master to be the same if there was nothing new in dev.

As a more general comment, the easiest way to figure out what's wrong with your history in cases like this is often to use a tool that shows you a graphical representation of the commit graph. For example, if you run gitk --all, you should be able to see where master and dev are, and why they aren't pointing to the same commit as you expect.

Also, it's worth noting that to avoid the confusion that might arise from rewriting published history, B may want to avoid doing the rebase when the dev branch contains published commits that haven't been merged to master.

Mark Longair
  • 385,867
  • 66
  • 394
  • 320