Merge or Cherry-Pick?

[Parker Coates]

On Wed, Feb 2, 2011 at 00:35, Dawit A wrote:
> I learned this the hard way, but it is even more problematic, at least
> for me, when you attempt to learn how to adapt or re-learn how to do a
> particular workflow with git. For example, let us take one of the
> things Alexander mentioned in his email:
>
> * for committing a trivial change to master/trunk
>
> If you only had a single change that is already committed into your
> local repo, then I guess it is simple enough and can be pushed to the
> origin master branch by doing:
>
> git pull --rebase
> git push
>
> But how would a similar work flow except there are multiple fixes
> present in the local repo ? How would you push only a single fix in
> such case ? It does not seem possible to me to do that... If that is
> the case, does it mean we have to create separate branches for each
> and every fix we work on since branches are cheap to create in git ?
> Or simply wait until we are ready to push all the changes and do them
> at once ? What if that is not desirable, i.e. an urgent fix that needs
> to be committed ?

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