> > 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. >
How about also add the flexibility to do individual PRs for each jira sub-task? That would still allow for tracking a commit per Jira. It wouldn't be as easier for tracking backports, but there may be scenarios where would make sense to commit individual jira sub-tasks ahead of the whole, completed feature. Em qua., 19 de fev. de 2020 às 20:05, Andrew Purtell < [email protected]> escreveu: > 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 >
