Merge or Cherry-Pick?

[Felix Rohrbach]

Am Mittwoch, 2. Februar 2011, 11:46:20 schrieb Wolfgang Rohdewald:
> On Dienstag 01 Februar 2011, Thiago Macieira wrote:
> > > That's not always true. Some changes will be specific to
> > > 4.6, because sections of code in master can get rewritten,
> > > features added or removed, so the changes won't be
> > > applicable there.
> > 
> > That's not a problem or an excuse.
> > 
> > Make the change in 4.6, merge to master, fix the conflicts and
> > then push both  branches.
> 
> if I continue developing the app in master and fix some bugs on
> the way, the fixes will be in master first. I would not always
> want to put them into 4.6 at once because testing in master is
> much easier and comes at much less cost while development goes
> on. So I might even want to wait some days or even weeks until
> backporting fixes.

You could try using a new local branch for every new feature or bug fix that 
you only merge into master if you want to push it to origin (so master is 
nearly always the same as origin/master). If you work like this, you can:
1. Create your fix in <someLocalBranch>
2. merge <someLocalBranch> into master
3. rebase <someLocalBranch> on 4.6 branch
4. merge <someLocalBranch> into 4.6
5. push :-)

Regards,
Felix Rohrbach