Merge or Cherry-Pick?

[Alexander Neundorf]

On Wednesday 02 February 2011, John Layt wrote:
> On Wednesday 02 February 2011 13:43:04 Parker Coates wrote:
> > My preferred workflow is to put all local commits intended for master
> > in a single, local, long-lived "workmaster" branch instead of putting
> > them in master directly. Since the changes are local, you can just
> > keep rebasing it onto master every time master is updated.
> >
> > Then if you want to push a single commit from the work branch:
> >     * pull master
> >     * you interactively rebase the workmaster branch onto master to
> > put the desired commit first
> >     * merge the SHA you want to commit into master
> >     * push master
> >
> > I find that by keeping my commits out of master itself allows me to
> > update without worries, to commit high priority fixes without messing
> > up my local work, and to commit early and often locally while still
> > having the option to clean things up later with some rebasing.
> >
> > Personally, I found this ability to keep my local commit queue out of
> > the way was the biggest advantage of switching to Git.
> >
> > Parker
>
> Personally, I think you should NEVER have commits in master, you should
> only ever work in and push from branches, they're so cheap to do.  That way
> your master is always a clean pure copy of the main repo to branch off.

I don't really care how it will be, but I really think we should agree on one 
common recommended and documented workflow to use.

Alex