Git and working on multiple branches

2019-01-10 03:51发布

问题:

I have a couple of Git branches: 'experimental', 'something' and 'master'.

I switched to the 'experimental' branch. I noticed a bug which is unrelated to 'experimental' and belongs to changes which have been made in 'something'. How should I fix it?

I'm thinking I should switch to 'something', fix the bug, commit and then move back to 'experimental'. How should I take the minor change from 'something' and apply it to both 'master' and 'experimental' so that I don't have to re-fix the bug again when I switch into these branches?

回答1:

There are two solutions not mentioned already that you can use: use a topic branch or use cherry-picking.


Topic branch solution

In the topic branch solution, you switch to branch 'something', create a branch to fix a bug e.g. 'something-bugfix', merge this branch into 'something' (fixing the bug), then merge this branch into 'experimental'.

$ git checkout -b something-fix something
[edit, commit]
$ git checkout something
$ git merge something-fix
$ git checkout experimental
$ git merge something-fix
[fix conflicts if necessary and commit]

See also Resolving conflicts/dependencies between topic branches early and Never merging back, and perhaps also Committing to a different branch blog posts by Junio C Hamano (git maintainer).


Cherry-picking a bugfix

The cherry-picking solution is useful if you noticed later that the bugfix you created (e.g. on development branch) would be useful also on other branch (e.g. stable branch). In your case you would comit a fix on 'something' branch:

$ git checkout something
[edit, edit, edit]
$ git commit
$ git checkout experimental

Then you noticed that fix you comitted in 'something' branch should be also on 'experimenta' branch. Lets say that this bugfix was commit 'A' (e.g. 'something' if you didn't commit anything on top of 'something', but it might be e.g. 'something~2' or 'c84fb911'):

$ git checkout experimental
$ git cherry-pick A

(you can use --edit option to git cherry-pick if you want to edit commit message before comitting cherry-picked bugfix).



回答2:

you could:

  • stash or commit the changes you have been working on the experimental branch
  • checkout something
  • (optional) bisect to find the bug
  • commit the changes
  • checkout experimental

and then:

  • rebase something if you want a clean commit graph (if you expose this repository and you care about that)

or:

  • merge something if you don't care about 'presentation' :)


回答3:

since your experimental branch has features from something you should do one of the:

  • merge something into experimental after you fix the bug there.
  • rebase your experimental on top of something


回答4:

If you don't progress in 'master' too much, just switch back to the experimental and do 'git merge master'. If you do, I think the 'git cherry-pick' command is your friend.



回答5:

Your branches are somehow related like this:

master > something > experimental

This is, if you really intend to merge something into master.

I would if possible, fix it on top of master, then rebase the others on top of master. But I simply like rebasing. Or you could fix it there and then merge exactly like that

master > something > experimental

but if something is a simple topic branch, I would not do that. Here it sounds like something is your "candidate next master"



回答6:

If you can merge, then do so. If you don't want to merge something into the other branches, then fix the bug and cherry-pick that commit into each of the other branches.