On Thu, Jul 9, 2009 at 10:15 PM, Tekkub<[email protected]> wrote: > You might want to check out git cherry-pick and git rebase... and train your > devs to prefer many small commits over few large ones, so you can pick and > choose what you want.
Yes; we'd certainly cherry-pick to merge the desired commits *before* doing what I suggested. I haven't explored rebase in practice. I'm sure I'll get to it, eventually. > You should also encourage them to make a branch for every new thing they > work on, never work on multiple features/bugs in the same branch. For that > matter, discourage working directly in master (this includes you), work in > branches and only merge to master. When you have many people on a project > this makes things much more manageable. Sounds like good advice. If the change(s) we wanted to cherry-pick had instead been done in their own branch(es), we could have just merged those branches into the master and release shared branches. We would not have had to do any cherry picking, and moreover we would not have had to merge from the release to the master branch, and we therefore never would have had to worry about excluding the non-cherry-picked commits when doing such a merge. -P. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/github?hl=en -~----------~----~----~----~------~----~------~--~---
