Обсуждение: git gururs

Dave,

You'll probably get a dozen different answers as different git
workflows work better for different people and different projects, but
this is what I've used on the driver when we maintained a fork of it
at Truviso.

> Can I just push to the real jdbc remote ?

Yes. I prefer to have "private" repositories for everyone on the
project, and one canonical one for the changes, but there's nothing
special about that one. You just never want to edit history (rebase,
filter-branch) that's been sent to that repo (you want to avoid that
in general, but it's a mortal sin to do that in a canonical project
history).

> Next how to backpatch.

Git cherry-pick is probably the right tool for this. Commit on master,
and cherry-pick that commit from all branches you want to back-patch
to (note that due to the way git names commits, you can just say "git
cherry-pick master" to grab the latest commit from master). If the
most recent release branch has not diverged from master (that is, all
commits on master are also on this branch), you can just merge master
into the branch (a fast-forward merge) to make it current. It will do
the same thing as a cherry-pick, but more simply.

This is fairly simple, but just as importantly, it keeps the semantics
you want: you are making changes to master (trunk), but back-porting
them to select branches. It also keeps the commit history fairly
clean.

On 11/02/2012 03:13 AM, Maciek Sakrejda wrote:

> Git cherry-pick is probably the right tool for this. Commit on master,
> and cherry-pick that commit from all branches you want to back-patch
> to (note that due to the way git names commits, you can just say "git
> cherry-pick master" to grab the latest commit from master). If the
> most recent release branch has not diverged from master (that is, all
> commits on master are also on this branch), you can just merge master
> into the branch (a fast-forward merge) to make it current. It will do
> the same thing as a cherry-pick, but more simply.
>
> This is fairly simple, but just as importantly, it keeps the semantics
> you want: you are making changes to master (trunk), but back-porting
> them to select branches. It also keeps the commit history fairly
> clean.
I'd second that. git cherry-pick is very useful. The other tool I use a
fair bit is `git merge --squash` when I want to compact the contents of
a messy working branch down to a single commit. I usually prefer to `git
rebase --interactive` the working branch to clean it up then `git merge`
it into the target branch, but that isn't always practical.

The main thing I find to be important is to maintain clear, discrete
units of work, not change sets that fix X and Y and add Z. That way you
can easily keep track of the fact that change <x> is in branches A, B and C.

--
Craig Ringer