Merge or Cherry-Pick?

John Layt johnlayt at
Wed Feb 2 14:05:42 GMT 2011

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.


More information about the kde-core-devel mailing list