Merge Workflow
We are using GitHub's merge button to squash and merge pull requests (PRs). This is a fast workflow for the people responsible for merging PRs, but it may alter metadata associated with your commit. After discussing this in #1374, the solution we went with is letting the user who makes the PR decide if they are fine with the default, or if they want their PR to be merged on the command line.
Merge on GitHub
Clicking the merge button. We always use "squash and merge" to have the entire PR as it was tested and reviewed as one commit in the git log (instead of many commits). If necessary, rebases are done on the command line and pushed to the PR branch to make continuous integration run on the rebased version.
Metadata:
- GitHub will replace your e-mail with
username@users.noreply.github.com
when you enable "Keep my email address private" - It may also change the timezone information of the squashed commit (#1374 (comment) indicates that)
Advantages:
- PR shows up as "merged" instead of "closed" (as if it was abandoned)
- Less work for people responsible for merging
Merge on command line
We would use the following lines to squash and merge PRs:
$ git fetch origin pull/1/head:pr1
$ git checkout pr1
$ git rebase
if there were any conflicts that needed to be resolved, it should be pushed to
the PR branch at this point. When continous integration ran through:
$ git checkout master
$ git merge pr1
Metadata:
- Does not get modified by GitHub
Always squash the commits?
In order to maintain a clean history of commits (without commits such as "fix spelling error", "restart tests" that may be part of a PR), we squash the whole PR into one commit. However, an exception can be made (example: #1421) in case all of the following apply:
- each commit has a good message
- there are no clutter commits that are minor fixes to the previous commits
- commits were reviewed independently
- two commits did not change the same code (e.g. each commit changes one package in aports)
With that being said, it would make reviewing much easier if individual pull requests were created instead.
Here's how PRs can be merged without squashing on the command line.
$ git fetch origin pull/1/head:pr1
$ git checkout pr1
$ git rebase
if there were any conflicts that needed to be resolved, it should be pushed to
the PR branch at this point. When continous integration ran through:
$ git rebase -i master
replace "pick" with "reword" to change the commit message and add the PR ID at the end
$ git checkout master
$ git merge pr1