Re: Help designing work flow

John Tapsell wrote:

2009/3/9 Andreas Ericsson [off-list ref]:

quoted

John Dlugosz wrote:

quoted

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.