Merge or Cherry-Pick?

[Parker Coates]

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.

Parker