Merge or Cherry-Pick?

John Tapsell johnflux at
Wed Feb 2 14:41:40 GMT 2011

On 2 February 2011 14:23, Parker Coates <parker.coates at> wrote:
> On Wed, Feb 2, 2011 at 09:05, 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.
>> 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.
> Hmm. You're probably right. The majority of my Git experience has been
> with git-svn where it's pretty much mandatory to commit via master. In
> a pure Git environment, I guess it should be possible to keep master
> 100% clean.

It seems that I go against the grain, and always develop in master.

You already have "origin/master" as a pristine version of upstream
master, and you don't have to worry about it getting out of sync.


git log   #find SHA1 of commit  I want to push upstream

git checkout origin/master  #we are now on an "unnamed" branch

git cherry-pick SHA  # still on an 'unnamed branch'

#compile, test, fix, etc.

git push origin HEAD:master

git checkout master

git pull --rebase   #rebase on top of remote, which now has our change


More information about the kde-core-devel mailing list