[core-workflow] GitHub Workflow

[Chris Angelico]

On Fri, Mar 18, 2016 at 4:44 AM, Oleg Broytman <phd at phdru.name> wrote:
> On Fri, Mar 18, 2016 at 04:35:17AM +1100, Chris Angelico <rosuav at gmail.com> wrote:
>> On Fri, Mar 18, 2016 at 4:17 AM, Oleg Broytman <phd at phdru.name> wrote:
>> >> I don't understand the cherry-pick:  why not just merge the rebased
>> >> feature branch with 'git merge --squash', and fix up the changelog in the
>> >> commit message of the merge commit?
>> >
>> >    That would require a lot of manual editing of the commit message
>> > while interactive rebase and cherry-pick preserve messages.
>>
>> There are some definite oddities to the workflow. For instance, using
>> "reword" followed by "fixup" lets you edit the original commit's
>> message, but without any reference to the subsequent commits; in
>> contrast, using "squash" would have shown all the messages - and every
>> version of git that I've ever used has permitted a squashed commit's
>> message to be edited, so either that's super old or there's some other
>> reason for this.
>
>    Fixup (during an interactive rebase) combines commit messages.

Fixup discards the subsequent message(s); it's absolutely awesome for
the case where your initial message was perfect (eg when you're
patching in a typo fix or something), but for this workflow, they're
editing the message anyway.

>> Personally, I don't believe in squashing the commits of a PR/merge (I
>> see the sub-history as important, not just the history of "this
>> feature was merged in" - although for trivial changes, where there's
>> one simple commit and then a follow-up to fix a typo or something,
>> maybe it's tidier), but if that's what you want, I'd simply rebase the
>> feature branch to squash it (at the same time as rebasing it onto the
>> latest master), and then merge. Way WAY simpler.
>
>    Me too. I have never used squashed merge. But "branchiful"
> development has its own troubles like problems with bisect.

Yes, it does. Most of the time, you can just rebase the commits into a
linear history and run with it; since git retains separate Author and
Committer names and timestamps, you can give proper credit to the
contributor, while still ordering things appropriately. If you want to
retain the history of "this group of commits did one job" without
losing the commits themselves, you have to use merges. Otherwise, it's
one or the other.

One of the beauties of git is that it allows myriad workflows. One of
the great difficulties of getting started with git is that it allows
myriad workflows. The curse of choice, multiplied out. :)

ChrisA