Re: git gururs
От | Craig Ringer |
---|---|
Тема | Re: git gururs |
Дата | |
Msg-id | 5094C905.5060505@ringerc.id.au обсуждение исходный текст |
Ответ на | Re: git gururs (Maciek Sakrejda <m.sakrejda@gmail.com>) |
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: