<div dir="ltr">> <span style="font-family:arial,sans-serif;font-size:13.333333969116211px">So when the code is ready, the feature branch including any accumulated commits (history) will</span><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">> get merged - and not a clean diff against the main repo?</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">I'm very far from being a git expert. In fact, I'm kind of the opposite - git and I have a stormy relationship and everyone has to tell me what to do.</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">But, I believe this is what git rebase is mainly used for. You can rebase your branch against an updated master and (I'm guessing) make your changes look like a single diff. Some people don't like that as it changes history, others do like it and say yes, that's the point - clean up the history so the commit log isn't full of tiny changes that were all made in order to effect some change (i.e., address a given ticket/issue).</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">I'm REALLY far from being a git pro, so someone else should confirm/correct this.</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">Terry</span></div><div style><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br>
</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 4, 2013 at 9:43 PM, Tobias Oberstein <span dir="ltr"><<a href="mailto:tobias.oberstein@tavendo.de" target="_blank">tobias.oberstein@tavendo.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Terry,<br>
<br>
thanks alot for your detailed explanation of a workflow. For me, that sounds reasonable and workable.<br>
<div class="im"><br>
>At some point everyone who's interested will have contributed to the discussion, to the code, and signed off.  Then you merge it, using the web UI<br>
<br>
</div>So when the code is ready, the feature branch including any accumulated commits (history) will get merged - and not a clean diff against the main repo?<br>
<br>
Just asking .. guess there are arguments for both approaches.<br>
<div class="im"><br>
>One point of difference that I don't know the best answer to: We tend to each have our own fork of  a repo, and to send pull requests into the repo "owned" by the organization. Others (including Github >themselves) just have one repo and anyone can make a branch in that repo and propose it for merging into the master of the same repo.  I think I prefer the former, though it has a little more overhead and it >requires people to do a git remote add git@github.com:name/project.git for the other people whose changes you want to track and pull in etc (via git remote update --prune).<br>

<br>
</div>+1 for the former (each has it's own repo). p2p scm.<br>
<div class="HOEnZb"><div class="h5"><br>
/Tobias<br>
<br>
_______________________________________________<br>
Twisted-Python mailing list<br>
<a href="mailto:Twisted-Python@twistedmatrix.com">Twisted-Python@twistedmatrix.com</a><br>
<a href="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python" target="_blank">http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python</a><br>
</div></div></blockquote></div><br></div>