Re: How to merge branches except for one commit

[Andreas Ericsson <ae@op5.se>]

Andrew Arnott wrote:
> Interesting.  I think working in the maintenance branch and merging
> back into master should work... except when I'm in master when I find
> the bug and just fix it there without thinking.
> 

That's when you cherry-pick and reset. While having your maintenance
branch checked out (after having committed on master), do

	git cherry-pick master
	git checkout master
	git reset --hard HEAD^

Later, when you merge in the maintenance branch again, you get the
bugfix you cherry-picked onto maint.

On the subject of your workflow though, I think you could definitely
benefit from using topic branches (short-lived branches with a few
commits to implement one particular feature/bugfix/whatever) so that
when you later decide to use a release-branch, you simply merge the
topics you want. For preference, bugfix topics should go into your
maintenance branch (branch v1.0 in your case), and then the entire
maintenance branch should be merged into master, so that master gets
all the true and tested bugfixes without you having to verify them
twice (assuming clean merges, ofcourse).

> The merge and revert idea is interesting.  I may try that out in this
> case since I'm already stuck with lots of commits in master.
> 
> Regarding why I am porting more than just *some* commits to the
> maintenance branches, well, these are also stabilization branches
> before an initial vX.0 release, so in the month or so of stabilization
> there could be potentially be a great deal of work in master that I
> decide is worth releasing sooner rather than later.

Why though? Don't you go into feature-freeze when you cut the branch?
If you don't, then where do you?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231