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

[Rob Miller]

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?

Rob

On 16 Jul 2013, at 15:54, Luke Morton wrote:

> We don't even use feature branches. We always work on the same develop
> branch so it'd be a massive headache to have a cleaner history for us. 
> I
> wish we could though.
>
> Magic answer someone?
>
>
> On 16 July 2013 15:52, Jon Wood <jon at ninjagiraffes.co.uk> wrote:
>
>> At least in our case we gracefully side step that issue by never 
>> having
>> multiple people working on a feature branch, but now you bring it up 
>> it may
>> turn out not be scalable as we get larger.
>>
>>
>> On 16 July 2013 15:51, Luke Morton <lukemorton.dev at gmail.com> wrote:
>>
>>> What if multiple people are working on a feature branch? Don't you 
>>> get
>>> problems with forced pushes?
>>>
>>>
>>> On 16 July 2013 15:46, Rob Miller <rob at bigfish.co.uk> wrote:
>>>
>>>> We interactively rebase branches (and then force push) before 
>>>> merging
>>>> them. Although it's a more manual process than, say, squash merges, 
>>>> the end
>>>> result is the best of both worlds: a record of the history of 
>>>> changes, but
>>>> one that isn't cluttered with "oops, forgot to include X"-type 
>>>> commits.
>>>>
>>>> Rob
>>>>
>>>>
>>>> On 16 Jul 2013, at 15:31, Chris Adams 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<https://github.com/blog/1557-github-flow-in-the-browser>
>>>>> http://scottchacon.com/2011/**08/31/github-flow.html<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<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<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
>>>
>>>
>>