<div dir="ltr"><div dir="ltr" style="font-family:arial,sans-serif;font-size:13px">My preference is to have small commits, but not necessarily "show my working". e.g. if I put something up for review, and comments suggest an alternative approach, I won't just add new commits on top to mutate the code in that direction, I'll go back and change stuff.  Well, in reality, I probably will add new commits when I'm working, but before putting it back for review I'll do some rebase magic to make it look otherwise.<div>
<div><br></div><div>It breaks the "don't force push to origin" rule, but I think that's ok, if it's a feature branch and you are using origin as the review host.</div></div><div><br></div><div>I'll also rebase against master / develop / whatever the canonical work branch is before merging it in, and merge with a git merge --no-ff so we have a nice flat history line with sensible merge points.</div>
<div><br></div><div>That useful?</div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 16 July 2013 15:31, Chris Adams <span dir="ltr"><<a href="mailto:wave@chrisadams.me.uk" target="_blank">wave@chrisadams.me.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi chaps<div><br></div><div>This is little off-topic, as it doesn't purely apply to Ruby, but hopefully it should be useful.</div>
<div><br></div><div>We're using something like a github pull request based workflow where I'm working for getting code into master for deploy - it's described in the links:</div>
<div><br></div><div><a href="https://github.com/blog/1557-github-flow-in-the-browser" target="_blank">https://github.com/blog/1557-github-flow-in-the-browser</a><br clear="all"><div><a href="http://scottchacon.com/2011/08/31/github-flow.html" target="_blank">http://scottchacon.com/2011/08/31/github-flow.html</a><br>

</div><div><br></div><div>However, having a nice tidy git history is a good thing on a codebase, and when merging this in, by default all the bitty commits are added in along with the merge, leaving a fairly messy history.</div>

<div><br></div><div>Anyone on the list found a nice way to combine the transparency and code review of a pull request based workflow, with the tidiness a well maintained git history?</div><div><br></div><div>Extra points for writing in ruby pseudo code.</div>

<div><br></div><div>Ta, <span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Chris</div><div><br></div><div><br></div><div><br></div><div><br></div>
<div><br></div>-- <br><div dir="ltr">Chris Adams<br><br><div>mob: 07974 368 229<br>tel: 0203 322 5777<br>
skype: chris.d.adams<br>twitter: mrchrisadams<br></div><div>www: <a href="http://chrisadams.me.uk" target="_blank">chrisadams.me.uk</a></div></div>
</font></span></div></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>