Re: Help designing work flow

> 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.
>