How to temporarily unbranch?

Question

I started a feature branch B from branch A. Then I made some changes in both. Merging A into B and then B into A results in both heads pointing at the same merged commit (which is what I wanted because changes in A should also affect branch B). Now for a while only A will experience changes.

Is there a way to make B stick to A until I checkout B and make a commit there? I could of course just delete B and recreate it when branching of again, or work with A and merge it into B before branching off again, but that all relies on me remembering my intention...

Answer 1

No, you can't stick B to A like you described it.
You already list the alternative options. I'd just delete B, that makes sure that you remember that you have to branch again :)

Answer 2

If you again merge A to B, it should jump forward to meet A, and then you simply start committing against B again.

Answer 3

You could let B be a patch queue (using something like quilt) on top of A. Then you can work on it at your leisure; each time you want to update to the newest version of A, you pop off your patches, update A, and then fuzz your patches back on again and fix whatever's broken.

Mercurial actually has an in-core extension for doing this easily and keeping the patches under revision control.

I do this all the time, and it works out really well when you're toying with a bunch of ideas that aren't ready for commit.

Is that what you're looking for?

Answer 4

Lets say you have a master branch with you main code line. Then you decide to implement a new foo feature, and create a new branch foo for that. Then you happily commit to foo, developing your feature, and find you there's a bug in your master branch. In this case, the usual git workflow is to checkout master a fix the bug there. Then, when you continue to develop your feature, you checkout foo, and bring it up to date with your master branch using git merge master. Then you have everything in order and there's no need to stick anything anywhere.

(Or, you can forget to update foo and merge the changes when you later merge foo to your master branch.)

Answer 5

I assume B's real name is sufficiently evocative that merely seeing it in the output of git branch or in the display of gitk --all is enough to remind you of the cool new feature you eventually want to add.

Next time you make changes to A and want to make B catch up, check out B and advance it to A's head. You wrote that A and B currently both point to the same commit. Down the road when you've made changes to A, B's history will still contain nothing that isn't already in A's, so this is an easy rebase:

git rebase A B

The previous command checks out B, so when you're ready to continue working on A:

git checkout A