I think every new feature/task should be on a new branch especial more than one people work on that.
the model is almost ok, but I still have some suggestions. 1, you can use `grb` for easy to manage branch, `sudo gem install grb`, `grb --help` for full usage. 2, you can setup an CI server, for continuous automate test after every push. 3, write some rake tasks to do the boring/duplicate work. On Wed, Mar 3, 2010 at 12:12 PM, Phlip <[email protected]> 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. > > Use a command line front-end, such as rake, and create miniature rake > tasks that pull, test, and push your code. > > Push and pull from the same repository. Use TDD and "continuous > integration", and integrate each time the code grows even a tiny bit > better. > > Doing it like this completely flattens the odds of "integration hell". > Just because the integration is automated doesn't make it any less > hell. > > 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. > > -- > Phlip > http://c2.com/cgi/wiki?ZeekLand > > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby > -- Best regards ------------------------ Zhang Jinzhu (Juice) github.com/jinzhu -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
