Re: git gururs
От | Maciek Sakrejda |
---|---|
Тема | Re: git gururs |
Дата | |
Msg-id | CAOtHd0AqkT4iUPej1PhNoZrRmA-K0Eyu+FAR+gV6h6TJBMgDmg@mail.gmail.com обсуждение исходный текст |
Ответ на | git gururs (Dave Cramer <pg@fastcrypt.com>) |
Ответы |
Re: git gururs
|
Список | pgsql-jdbc |
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.
В списке pgsql-jdbc по дате отправления: