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 \'e
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.
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.
you could:
stash
or commit
the changes you have been working on the experimental
branchcheckout something
bisect
to find the bugcommit
the changescheckout 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' :)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"
There are two solutions not mentioned already that you can use: use a topic branch or use cherry-picking.
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).
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).
since your experimental branch has features from something you should do one of the: