An interesting example of GitHub Workflow (used by Frameworks team at BBC News): http://www.integralist.co.uk/posts/github-workflow.html The basis of their workflow is this: -- Open a GitHub PR (Pull Request) by creating a new feature branch from master -- Make feature specific changes and request a code review -- If given a "thumbs up", this means the PR author is allowed to handle merging the PR -- The merge process requires a set of sub steps (see below) The steps (in summary) are: -- Interactively rebase master onto the feature branch -- Squash all feature commits into a single commit: -- (this isn't exactly a squash) -- the first line of the commit message should be the same as the GitHub PR title -- As part of the rebase ensure: -- the author(s) is mentioned in the commit message -- the PR is mentioned (and any associated issues as well) -- Move back to the master branch and cherry-pick in the newly squashed feature commit Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/17/2016 05:48 AM, Oleg Broytman wrote:
-- Interactively rebase master onto the feature branch
The directionality seems wrong here: one would be rebasing the feature branch onto the head of `master`: "rebase master" would mean "rewrite master's history", which cannot be correct.
-- Move back to the master branch and cherry-pick in the newly squashed feature commit
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? Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW6rubAAoJEPKpaDSJE9HYeScP/3oG/duoBb4RFJz4vxuN1+Or a/sqc2GK3mGWs2G4HpcCIJl2jdOqsT3zvB7//Mp2DbcCwaBnQB4wg8BqBZN7z+lO Qw7zNOerJpMjaQarVIMCtGi/vPkpN8ZPbM9y5qwhjDfywxD62aV/+H7yAg2rw+PY 5HfstwDDTiDdHiaa7MUrKTuVO6X5h1p0ZITpaCLZuGYf9tL17Ly3vaoZOe7SNz2/ k9w6TT6hNiD0YYdiNYv5ettD9o4UjQbQThHUmV0dQ1umcn6+GAEEX3w8xh5ewMcH MVC/Ptx32zDRqN411fguudJv2IzOB1m1nJnpQjG9KQ0ZSqNdYAgCj9fb9eRWue2M TuDDHOX/RLlOXGBi/vtbzF1bldnUDRF3mlEmFosNvLbDGdhrGE+NKEqCTq9kylE6 QsqPeCbVaxjU3gc705hKGFm0Owqg0Kacc8HXIZXYY/aRNpGPEFYq+e1wlUOThFiE f7rcFJOPBDhz9gsbhcUNwV/97MZ0dO9kqwKfcV9NVYNssk1aj/XZEnajMACdBQ4t WJdCuiAeGefVSEKmxegM6GK7jI12auf95zG9NeqHPkyGhcnSknp7z9V2yAzmcjFt ZohcrJKtLffPS8Fc2rFK8jaQjWCtmOMLBwPardq3eCtpHv35MS/W0FNRuL2f5MJX LAJSqpbiJfEsv/uFSDDm =952r -----END PGP SIGNATURE-----
On Thu, Mar 17, 2016 at 10:13:53AM -0400, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/17/2016 05:48 AM, Oleg Broytman wrote:
-- Interactively rebase master onto the feature branch
The directionality seems wrong here: one would be rebasing the feature branch onto the head of `master`: "rebase master" would mean "rewrite master's history", which cannot be correct.
It seems they rebase non-pushed commits in master onto the feature branch.
-- Move back to the master branch and cherry-pick in the newly squashed feature commit
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.
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQIcBAEBAgAGBQJW6rubAAoJEPKpaDSJE9HYeScP/3oG/duoBb4RFJz4vxuN1+Or a/sqc2GK3mGWs2G4HpcCIJl2jdOqsT3zvB7//Mp2DbcCwaBnQB4wg8BqBZN7z+lO Qw7zNOerJpMjaQarVIMCtGi/vPkpN8ZPbM9y5qwhjDfywxD62aV/+H7yAg2rw+PY 5HfstwDDTiDdHiaa7MUrKTuVO6X5h1p0ZITpaCLZuGYf9tL17Ly3vaoZOe7SNz2/ k9w6TT6hNiD0YYdiNYv5ettD9o4UjQbQThHUmV0dQ1umcn6+GAEEX3w8xh5ewMcH MVC/Ptx32zDRqN411fguudJv2IzOB1m1nJnpQjG9KQ0ZSqNdYAgCj9fb9eRWue2M TuDDHOX/RLlOXGBi/vtbzF1bldnUDRF3mlEmFosNvLbDGdhrGE+NKEqCTq9kylE6 QsqPeCbVaxjU3gc705hKGFm0Owqg0Kacc8HXIZXYY/aRNpGPEFYq+e1wlUOThFiE f7rcFJOPBDhz9gsbhcUNwV/97MZ0dO9kqwKfcV9NVYNssk1aj/XZEnajMACdBQ4t WJdCuiAeGefVSEKmxegM6GK7jI12auf95zG9NeqHPkyGhcnSknp7z9V2yAzmcjFt ZohcrJKtLffPS8Fc2rFK8jaQjWCtmOMLBwPardq3eCtpHv35MS/W0FNRuL2f5MJX LAJSqpbiJfEsv/uFSDDm =952r -----END PGP SIGNATURE-----
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Fri, Mar 18, 2016 at 4:17 AM, Oleg Broytman <phd@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. 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. ChrisA
On Fri, Mar 18, 2016 at 04:35:17AM +1100, Chris Angelico <rosuav@gmail.com> wrote:
On Fri, Mar 18, 2016 at 4:17 AM, Oleg Broytman <phd@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.
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.
ChrisA
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Fri, Mar 18, 2016 at 4:44 AM, Oleg Broytman <phd@phdru.name> wrote:
On Fri, Mar 18, 2016 at 04:35:17AM +1100, Chris Angelico <rosuav@gmail.com> wrote:
On Fri, Mar 18, 2016 at 4:17 AM, Oleg Broytman <phd@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
On Fri, Mar 18, 2016 at 05:14:52AM +1100, Chris Angelico <rosuav@gmail.com> wrote:
On Fri, Mar 18, 2016 at 4:44 AM, Oleg Broytman <phd@phdru.name> wrote:
On Fri, Mar 18, 2016 at 04:35:17AM +1100, Chris Angelico <rosuav@gmail.com> wrote:
On Fri, Mar 18, 2016 at 4:17 AM, Oleg Broytman <phd@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.
Ah, yes, it's "squash", not "fixup".
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
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Mar 17, 2016, at 06:44 PM, Oleg Broytman wrote:
Me too. I have never used squashed merge. But "branchiful" development has its own troubles like problems with bisect.
Only when you don't have a clear main-line-of-development (like git <wink>). But I usually don't squash merges or feature branches unless there's really a lot of cruft, bisect issues not withstanding. FWIW, here's GitLab's workflow: https://about.gitlab.com/2014/09/29/gitlab-flow/ Cheers, -Barry
participants (4)
-
Barry Warsaw -
Chris Angelico -
Oleg Broytman -
Tres Seaver