1

I have two developers working simultaneously, one on master (dev1) and one on another branch (dev2). The master is being treated as the "mainline". Dev1 regularly merges the changes from the branch of dev2 as follows:

git checkout master
git merge origin/branch1
git push origin master

This merges the branch with the master for a deployment, but dev2 also wants to get the latest changes from the master after the merge is complete. I am thinking this is the best approach:

git checkout branch1
git rebase master

Is this correct?

In Github, I noticed that the branch they were working on no longer appears and no one deleted it. I'm pretty sure rebase or merge will not delete the branch unless you tell it to. Let me know otherwise.

Basically, the graph would look something like:

     b1  b2   b3 b4...
    /      \ /     \
   m1   m2  m3  m4  m5...

m3 and m5 are where dev1 will merge b2 and b4, respectively.

occasl
  • 5,303
  • 5
  • 56
  • 81

3 Answers3

2

The rebase is only valid if dev2 is rebasing unpublished commits.

But dev2 rebased commits already pushed to origin (and potentially already merged by dev1 into master), then it is not the right approach, because the SHA1 are changed, and the next merge of branch1 by dev1 won't just merge new commits, but all commits, even those already merged.

In this specific situation, dev2 needs to merge master with git merge master – that will avoid those problems.

Chronial
  • 66,706
  • 14
  • 93
  • 99
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • What do you recommend then? Dev1 has merged the branch from dev2 and continues on in master, so what should dev2 do to get the latest merged results from master? – occasl Jan 31 '13 at 21:42
  • @Dev1 should not go on on master, but on dev1 branch. If master is there to reflect what is to be deployed, it should be separate from any dev branch. If dev2 has already pushed, then it should merge master, not rebase on top of it. But other branching models exist (http://dymitruk.com/blog/2012/02/05/branch-per-feature/, http://williamdurand.fr/2012/01/17/my-git-branching-model/, http://alblue.bandlem.com/2011/11/git-tip-of-week-git-flow.html, ...) – VonC Jan 31 '13 at 21:54
  • @VonC Added your comment to your answer so I could upvote it :) – Chronial Jan 31 '13 at 22:51
1

Github doesn't show you merged branches.
Use:

git branch --merged

To list all merged branches

You could use

git log --graph

To view your commit graph to see where each branch was merged

Rushil
  • 135
  • 1
  • 6
1

After researching this a bit more, I did find a blog post that seems to cover exactly what I originally asked in the question: http://mettadore.com/analysis/a-simple-git-rebase-workflow-explained/. That is, to not merge but instead rebase the branch with the master and vice versa. The main difference is that you don't ever push the local branch.

The main reason for this approach is that it would retain your branch history in the master and prevent an issue "when more than one person are working on a branch, because what if someone else pulls the master branch for a merge just as you are pulling the master branch for a merge?"

I'm adding this as another possible option, but I would be curious if anyone sees a problem with what's described in the blog.

occasl
  • 5,303
  • 5
  • 56
  • 81
  • rebase then merge is a workflow I always advocated for (http://stackoverflow.com/questions/804115/git-rebase-vs-git-merge/804178#804178, http://stackoverflow.com/questions/7062192/about-gits-merge-and-rebase/7062773#7062773), so... +1. – VonC Mar 26 '13 at 22:33