The committer guide in the book says squash merges are always preferred. When I was faced with a backport PR I referred to this and opted for squash-and-merge rather than rebase-and-merge as consequence. Let’s update that guidance with the extra process detail for backports of features spanning multiple commits/JIRAs.
> On Feb 19, 2020, at 8:25 AM, Sean Busbey <[email protected]> wrote: > > So long as the backport PRs are lazy consensus instead of the RTC that > a PR generally implies (and the original branch went through) then > this all reads as in line with my own preferences and what we've > mostly done historically. > >> On Wed, Feb 19, 2020 at 10:08 AM Nick Dimiduk <[email protected]> wrote: >> >> Hello, >> >> We have had a couple feature branches in flight recently. I would like to >> review our project policy regarding how we account for the merging of these >> feature branches to master and other release line branches. There has been >> some discussion on this topic around HBASE-18095, but I want to bring it to >> light outside of that context. Whatever we decide here, we should write up >> and include in the book. >> >> By way of process, my preference is that when we merge a feature branch, we >> retain all of the individual commits (one-to-one with Jira sub-tasks). >> Mechanically this means something like the following: >> (1) squash together all commits that correspond with a single Jira >> sub-task, making the history into one commit for one sub-task. >> (2) rebase the feature branch onto master; >> (3) create a PR from the feature branch into master; >> (4) use the "rebase and merge" option when merging the PR; >> (5) update the fixVersion of the umbrella and all sub-tasks to the >> version of master; >> (6) repeat steps 2-5 for each back-port. >> >> My reason for preferring preservation of sub-commit history is that, in the >> event of follow-on addendums and sub-task (something we have a habit of >> doing), its easy for release line maintainers to account for which of those >> follow-ons have been applied to their branches of interest. If the "squash >> and merge" option is chosen, it becomes much more difficult for a release >> manager (or indeed, curious historians) to identify exactly which Jira >> issues are present in the history. >> >> My reason for preferring PRs for merging feature branches (and back-ports) >> over a developer pushing manually is that it gives the maintainer an >> opportunity to benefit from the pre-commit robot, and >> back-port-branch-specific discussion to occur in the context of the code >> changes proposed. >> >> There are certainly other ways of going about this. I'm curious what others >> think of the above. >> >> Thanks, >> Nick
