[LRUG] Keeping a nice git history with a pull request workflow on github

Jon Wood jon at ninjagiraffes.co.uk
Tue Jul 16 07:46:16 PDT 2013


Consider this a second for Murray's advice. We have a very similar process
at Hubbub, where feature branches are considered exceptions to the rule of
not force pushing to origin. I find there's far more benefit in having
frequently rebased commits which encompass a logical set of changes as
opposed to endless commits which are just minor changes during code review.

Jon


On 16 July 2013 15:42, Murray Steele <murray.steele at gmail.com> wrote:

> 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.
>
> 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.
>
> 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.
>
> That useful?
>
>
>
> On 16 July 2013 15:31, Chris Adams <wave at chrisadams.me.uk> wrote:
>
>> Hi chaps
>>
>> This is little off-topic, as it doesn't purely apply to Ruby, but
>> hopefully it should be useful.
>>
>> 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:
>>
>> https://github.com/blog/1557-github-flow-in-the-browser
>> http://scottchacon.com/2011/08/31/github-flow.html
>>
>> 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.
>>
>> 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?
>>
>> Extra points for writing in ruby pseudo code.
>>
>> Ta,
>>
>> Chris
>>
>>
>>
>>
>>
>> --
>> Chris Adams
>>
>> mob: 07974 368 229
>> tel: 0203 322 5777
>> skype: chris.d.adams
>> twitter: mrchrisadams
>> www: chrisadams.me.uk
>>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20130716/57473925/attachment.html>


More information about the Chat mailing list