<div dir="ltr">We don't have a centralised way of code reviewing. We tend to do it (when we do it) before it gets pushed to the github develop branch at our own machines. If we made code reviewing more formal, couldn't you do it on a commit basis rather than a feature branch one?<div>
<br></div><div>I much prefer a team working on one branch rather than feature branching. It obviously has it's own pitfalls just like feature branching though.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 16 July 2013 15:55, Rob Miller <span dir="ltr"><<a href="mailto:rob@bigfish.co.uk" target="_blank">rob@bigfish.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My magic answer would definitely be feature branches — how do you do code review of a feature if you don't have all the commits related to that feature grouped together on a branch somewhere?<br>
<br>
Rob<div><div class="h5"><br>
<br>
On 16 Jul 2013, at 15:54, Luke Morton wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
We don't even use feature branches. We always work on the same develop<br>
branch so it'd be a massive headache to have a cleaner history for us. I<br>
wish we could though.<br>
<br>
Magic answer someone?<br>
<br>
<br>
On 16 July 2013 15:52, Jon Wood <<a href="mailto:jon@ninjagiraffes.co.uk" target="_blank">jon@ninjagiraffes.co.uk</a>> wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
At least in our case we gracefully side step that issue by never having<br>
multiple people working on a feature branch, but now you bring it up it may<br>
turn out not be scalable as we get larger.<br>
<br>
<br>
On 16 July 2013 15:51, Luke Morton <<a href="mailto:lukemorton.dev@gmail.com" target="_blank">lukemorton.dev@gmail.com</a>> wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
What if multiple people are working on a feature branch? Don't you get<br>
problems with forced pushes?<br>
<br>
<br>
On 16 July 2013 15:46, Rob Miller <<a href="mailto:rob@bigfish.co.uk" target="_blank">rob@bigfish.co.uk</a>> wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
We interactively rebase branches (and then force push) before merging<br>
them. Although it's a more manual process than, say, squash merges, the end<br>
result is the best of both worlds: a record of the history of changes, but<br>
one that isn't cluttered with "oops, forgot to include X"-type commits.<br>
<br>
Rob<br>
<br>
<br>
On 16 Jul 2013, at 15:31, Chris Adams wrote:<br>
<br>
Hi chaps<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
This is little off-topic, as it doesn't purely apply to Ruby, but<br>
hopefully<br>
it should be useful.<br>
<br>
We're using something like a github pull request based workflow where<br>
I'm<br>
working for getting code into master for deploy - it's described in the<br>
links:<br>
<br>
</div></div><a href="https://github.com/blog/1557-**github-flow-in-the-browser" target="_blank">https://github.com/blog/1557-*<u></u>*github-flow-in-the-browser</a><<a href="https://github.com/blog/1557-github-flow-in-the-browser" target="_blank">ht<u></u>tps://github.com/blog/1557-<u></u>github-flow-in-the-browser</a>><br>

<a href="http://scottchacon.com/2011/**08/31/github-flow.html" target="_blank">http://scottchacon.com/2011/**<u></u>08/31/github-flow.html</a><<a href="http://scottchacon.com/2011/08/31/github-flow.html" target="_blank">http://<u></u>scottchacon.com/2011/08/31/<u></u>github-flow.html</a>><div class="im">
<br>
<br>
However, having a nice tidy git history is a good thing on a codebase,<br>
and<br>
when merging this in, by default all the bitty commits are added in<br>
along<br>
with the merge, leaving a fairly messy history.<br>
<br>
Anyone on the list found a nice way to combine the transparency and code<br>
review of a pull request based workflow, with the tidiness a well<br>
maintained git history?<br>
<br>
Extra points for writing in ruby pseudo code.<br>
<br>
Ta,<br>
<br>
Chris<br>
<br>
<br>
<br>
<br>
<br>
--<br>
Chris Adams<br>
<br>
mob: 07974 368 229<br>
tel: 0203 322 5777<br>
skype: chris.d.adams<br>
twitter: mrchrisadams<br>
www: <a href="http://chrisadams.me.uk" target="_blank">chrisadams.me.uk</a><br></div>
______________________________<u></u>**_________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/**listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/**<u></u>listinfo.cgi/chat-lrug.org</a><<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">htt<u></u>p://lists.lrug.org/listinfo.<u></u>cgi/chat-lrug.org</a>><br>

<br>
</blockquote>
______________________________<u></u>**_________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/**listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/**<u></u>listinfo.cgi/chat-lrug.org</a><<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">htt<u></u>p://lists.lrug.org/listinfo.<u></u>cgi/chat-lrug.org</a>><br>

<br>
</blockquote><div class="im">
<br>
<br>
______________________________<u></u>_________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/<u></u>listinfo.cgi/chat-lrug.org</a><br>
<br>
<br>
</div></blockquote>
<br>
</blockquote></blockquote>
</blockquote></div><br></div>