Ralph Castain <r...@open-mpi.org> writes: > We go the other direction - all code must be committed to master so it > can “soak” prior to moving to a release branch.
Maybe we're miscommunicating. Normal lifecycle for a bug fix is # start from oldest maintenance branch to which the fix is relevant git checkout -b jed/bug-fix maint ... fix bug, commit, submit pull request, review, revise if needed # [optional] If using 'next' for eager users/testing prior to 'master' git checkout next git merge jed/bug-fix ... "eager" users test this bug fix in combination with everything else # feature graduates to 'master' git checkout master git merge jed/bug-fix ... users of 'master' interact with bug fix, bringing more confidence # feature merged to release/maintenance branch git checkout maint git merge jed/bug-fix At the end of the day, there is only one commit effecting the change and we can easily check who has it. If someone else needs the fix in their development branch, they can get it without side-effects by merging jed/bug-fix. The 'next' branch, which is entirely optional, helps further stabilize 'master' - bugs in 'master' *disrupt other developers* while bugs in 'next' only disrupt testing. Here's a diagram: https://docs.google.com/drawings/d/1hvwyCIw4Wq3NoRrPpWfPTriJn5MM2_QkaacAaql8FQE/edit The "merging upward" is about git checkout master git merge maint git checkout next git merge master These merges rarely contain non-merge commits (the topic branches were already merged to 'next' and then 'master'); they just tie up the graph so that subsequent merges only contain the "interesting" content. If instead, your workflow has you committing a bug-fix on 'master', you have to rebase/cherry-pick it to get it into a release branch without side-effects. Now your repository has two commits that do the same thing. A workflow should make it easy to get bug-fixes and features to different audiences (e.g., release users versus developers) without side-effects and without duplication. > The “upward” methodology works fine for stable situations where the > master isn’t changing much relative to the releases, I disagree. There are many agile projects that merge upward using topic branches, as described above.
pgpW_Tq0T84ls.pgp
Description: PGP signature
