Merging a pull request
Ensure tests are passing and the PR is merge-able.
Ensure the creating pull requests and getting them merged guideline is followed.
Ensure the branch is correct (lowest applicable maintained branch).
Ensure a proper commit message is written for the pull request according to commit message styleguide
Use pull request title and body (first PR comment that is always available and automatically created) for proper commit message used for the change log.
When merging the pull request, copy body text under the automatically inserted title in the “merge commit message”.
Update status on related Github issue
The log fetches the pull request title and body directly from Github, which allows fixing it post merge. However the body should still be copied when merging, since it provides better details in the actual Git log and in the GH commit overview.
All committers can do a branch merge if necessary. An upmerge is done by first merging the lowest maintained branch into the next higher maintained branch (which should be current stable) and then merging the result into master (or the next higher branch if more branches are supported, until you hit master).
Before you start merging, you need to set the merge strategy to “ours” to enable merge configuration stored in
.gitattributes used to avoid conflicts in built files:
git config merge.ours.driver true # optionally use the --global flag
In the following example the current stable is 2.0 and the old stable is 1.2:
git checkout 1.2
# makes sure that 1.2 is up to date
git checkout 2.0
# makes sure that 2.0 is up to date
git merge 1.2
Now you may need to resolve conflicts and finally commit the merge if an automatic merge was not possible.
git checkout master
git merge 2.0
Again you may need to resolve conflicts and merge the commit.
Commit the merge commit with the prefix
MERGE: Merge branch '1.2' into 2.0
to keep track of upmerges separately from PR and other branch merges.
If there are many conflicts you can use the
recursive strategy with the
ours option. This should be harmless in most cases but beware that this prefers the branch you are merging into. It might “drop” changes that should have gone in if the respective part was changed in both branches. This way of merging is mostly useful if changes that have a similar effect were merged manually to all branches (like a code style change or file header comment change). The upmerge should then be initiated right after those changes so you can be sure that nothing useful gets lost.
git merge -s recursive -X ours 1.2
# recursive ours merge of 1.2 into the current branch
Upmerging from Flow 3.3 to 4.0 or Neos 2.3 to 3.0 (namespace changes) leads to “deleted by them:” issues.
To circumvent this issue, the rename threshold has to be raised.
git config merge.renamelimit 10000
git merge origin/2.3 -s recursive -X 'rename-threshold=1%'