Re: Help designing work flow

[Andreas Ericsson <ae@op5.se>]

John Tapsell wrote:
> 2009/3/9 Andreas Ericsson <ae@op5.se>:
>> John Dlugosz wrote:
>>> I know we (my group) should use "topic" branches and apply them back to
>>> the dev branch when done.  There is concern that the commit history gets
>>> too full of detailed stuff, especially with several developers, that you
>>> can't tell what "really changed".  So, our dev branch should appear to
>>> contain only commit nodes representing completed assignments; not every
>>> day's checkpoint and trying to keep one's own stuff on top to avoid
>>> merging later.
>>>
>>> I guess that's how it is on these Open Source projects where patches are
>>> submitted by email and applied by the maintainer.  We don't see the
>>> details, just the final patch.  But, my situation will be developers
>>> gathered around an in-house master repo, and everyone should be able to
>>> push their own changes as assignments are completed.
>>>
>>> What is the best procedure to achieve that?  Or what are some good
>>> alternatives with trade-offs?
>>>
>> Use topic-branches and let someone merge them into master after having
>> verified that they work properly.
>>
>> We usually commit simple bugfixes directly to master and then have
>> developers rebase their changes onto master when they're ready to
> 
> The trouble with rebasing is that it then you end up with lots of
> patches that haven't been tested.  You can end up with lots of
> uncompiling commits.
> 

Not really, no. Unit-tests can still run just fine, and integration
testing still needs to be done after each feature is completed.

> Although merging is no better either.  Then you end up with one single
> commit that tries to merge two trees, making it almost impossible to
> track down bugs that resulted from the merge.
> 

Not really. If bugs are in "unrelated" areas (if the topic changed some
API without changing its' other callers, fe), you can backstep between
each commit on the merged branch, remerge that commit (instead of the
tip) and then run the tests again. But really, such bugs should have
been detected prior to merging the branch, and in any case "git bisect"
will find the commit that introduced the bug for you either way.


For next time, please cut away those parts of the email you didn't
reply to. I had to scroll down to the bottom to make sure you hadn't
written more.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.