On Mar 2, 2010, at 8:12 PM, Phlip wrote: > On Tue, Mar 2, 2010 at 5:10 PM, Scott Olmsted <[email protected]> wrote: > >> I want to handle merging their changes, so I've asked them to create >> branches 'task1', 'task2', etc. > > Never do that. The root principle of Git is it makes branching and > merging very easy, so you can easily avoid them at all costs. > > ... > > Only branch and merge if u have a customer-support emergency, and > don't want to put metadata barriers around new features that an old > customer is not ready for. Branch the labelled version of the code > they got, make their change, and merge & update as soon as possible.
Either I don't understand the meaning here, or I completely disagree. The whole point of git's branching system (IMHO) is so that you can do it all the time. Instead of allowing big branches to form, and thus big merges, you setup topic or task branches, just like Scott described. Then since each merge only handles a small change, you can do them easily. However, to Scott's original question about working with another person: I find it easier to let them do their own task branch merges, then push their master up to the central repo periodically (and when it's working correctly). Then I'm following the same process on my end. So we're both pulling from origin/master, branching, merging, and then pushing to origin/master. No topic branches are stored on the origin server, only maintenance branches and release tags. The advantage of this system is that it lets each developer create, switch, merge, and destroy branches as they need to, so that they can work at full-speed. It also prevents you from having to take over a (hopefully) un-needed release manager role. And lastly it does achieve what Philip was (I think) aiming at, by letting origin/master be your integration branch so that merges are kept current and simple. You certainly don't want to end up maintaining more long-term branches than you absolutely have to. -Nic -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
