5

Say I have a branch named feature that has been branched off master. Both, developer1 and developer2 checkout feature. developer1 commits a change to feature and pushes it. Then developer3 pushes something to master. At this point master and feature diverge, each having a separate commit.

What's the right way to go about getting the latest from master into the feature, if there are conflicts? Should I rebase master into the feature, or merge it in?

EDIT:

I should mention that in this case I would not want to rewrite the history on developer2. Because that would be bad. Right?

gylaz
  • 13,221
  • 8
  • 52
  • 58

3 Answers3

3

Considering feature branch is already shared, it shouldn't be rebased on master (as it changes its - shared - history).

A simple merge from master to feature will be enough (without speculating as why dev3 pushed to master in the first place).

As Adam Dymitruk comments, this is called a "back-merge", and, depending on the role you attribute to master, it is questionable: if master represents the stable production state, you should merge to master, not from master.

But again, my answer made no assumption on said role.

This is why the famous git-flow illustrates in its blog post merges which are coming to master (from, for instance, an hotfix branch, as I commented earlier)

git flow

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
2

git is a great tool; but, it cannot take the place of good communication among developers.

You have to ask whether the changes in master must also be included in feature. Ideally, a feature branch should have the smallest amount of code possible.

If the change(s) absolutely must be included in feature, then the you have basically two options: git rebase; and, git cherry-pick. I suppose you could perform a backward merge from master into feature; but, that can lead to bad situations...

cherry-pick allows you to apply a specific commit or multiple commits to the current HEAD, keeping comment and author information. After having successfully cherry-picked, git is smart enough to know that the two commits are the same when merging feature back into master. If it's just a few commits we're talking about, then cherry-pick should be sufficient.

rebase allows you to apply the current branch (line of commits) starting from a different point in history. As you pointed out, this can be troublesome for developer1 and developer2 who already have copies of feature. They would also need to rebase their local development onto the new feature branch.

At any rate, the commit directly to master by developer3 should have been in its own feature branch, and that feature branch should have been merged. That feature branch could then have been merged into feature as necessary. Assuming just one (the most recent) commit in master, you could rectify the situation as follows:

# Ensure clean working directory
$ git stash

# Create new branch at master
$ git branch some-descriptive-name master

# Move master back one commit
$ git checkout master
$ git reset --hard HEAD^

# Merge the new branch into master
$ git merge --no-ff some-descriptive-name

# Forcibly update master
#   YOU SHOULD COMMUNICATE WITH OTHER DEVS BEFORE DOING THIS
$ git push -f origin master

# Merge the new branch into feature
$ git checkout feature
$ git merge --no-ff some-descriptive-name

I cannot stress enough how valuable good communication is because these kinds of "oops" things can and do happen all the time.

Good luck!

EDIT:

The part about cherry-picking was written with the assumption that there was only a few commits (or just one) to master and that they all would be cherry-picked.

x -- y (master)
 \
  a -- b -- c (feature)
execjosh
  • 714
  • 7
  • 9
  • I don't like cherry-picking because of its limitation (http://stackoverflow.com/questions/881092/how-to-merge-a-specific-commit-in-git/881112#881112), duplicating dev3 commit. I would prefer a merge here. – VonC Oct 17 '12 at 06:28
  • I understand, but why cherry-pick said commits, duplicating them on `feature` branch, and making a future merge of `feature` back to merge potentially more problematic? – VonC Oct 17 '12 at 06:37
  • If you merge from master (reverse merge), you include *all* commits. This leads to very lengthy `bisect`s and the feature branch is no longer just the feature. Your point about cherry-picking is very valid. But, I think that performing surgery on `master` is the best way to handle the situation. – execjosh Oct 17 '12 at 06:38
  • True. But in this instance, we are talking about *one* commit, right? – VonC Oct 17 '12 at 06:40
  • Point taken ;) But, I still don't like the line going from `master` to `feature` :P – execjosh Oct 17 '12 at 06:43
  • 1
    Interesting: that (the line from master to feature) somehow doesn't bother me. As suspect the merge should have been done from an `hotfix` branch to `feature` (as illustrated in http://nvie.com/posts/a-successful-git-branching-model/), instead of `master` to `feature`: I just don't know from where `dev3` did his/her commit. – VonC Oct 17 '12 at 06:51
1

the third developer should not be writing a feature on master. The rare exception is a hotfix. But even then, it should be it's own branch then merged with --no-ff onto master. I've written a long post about branch per feature here: http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141