Jump to content

Merge Workflow

From postmarketOS Wiki
Revision as of 19:22, 1 June 2018 by Ollieparanoid (talk | contribs) (How to merge PRs without squashing on CLI (this can probably be done easier, but at least I have an initial workflow written down now))

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:

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