Merge or Cherry-Pick?

[John Layt]

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.  

If I needed to extract a single commit out of a branch to push, rather than 
merging it to master I'd create a new branch from master and cherry-pick the 
commit to that, build and test it knowing it's clean, then push from there.  
Then pull master and rebase the original branch on master again.

John.