You can allow contributors with push access to your repository to merge their pull requests on GitHub with different merge options or enforce a specific merge method for all of your repository's pull requests.

You can configure pull request merge options on GitHub to meet your workflow needs and preferences for managing Git history. You can enforce one type of merge method, such as commit squashing or rebasing, by only enabling the desired method for your repository.

When you click the default Merge pull request option on your pull request on GitHub, all your commits from the feature branch are added to the base branch in a merge commit.

standard-merge-commit-diagram

Squashing your merge commits

You can also squash the pull request's commits into a single commit. Instead of seeing all of a contributor's individual commits from a topic branch, the commits are combined into one commit once they're merged into the default branch, creating a more streamlined Git history. Pull requests with squashed commits are merged using the fast-forward option.

commit-squashing-diagram

Work-in-progress commits are helpful when working on a feature branch, but they aren’t necessarily important to retain in Git history. For example, these commits on a feature branch describe the same intended action:

git log
commit 342aa5ae7f24c911c4f082f376eef7fb9f26b852
Author: octocat 
Date:   Tue Sep 20 16:44:38 2016 -0700

 Finally fix the backport test

commit 32273764bc2cff3f576c114251115ebb3916bbf7
Author: octocat 
Date:   Tue Sep 20 16:04:18 2016 -0700

 Maybe fix that test?

commit 18686eae87dce534027af96a904a7bf900bb4885
Author: octocat 
Date:   Tue Sep 20 16:03:51 2016 -0700

 Oops! Fix typo.

If you squash these commits into one commit upon merging to the default branch, you can retain the original changes with a clear Git history.

git log
commit a356ad4a123895edfa2668e6e928dfee8ab22883
Author: octocat 
Date:   Tue Sep 20 17:04:38 2016 -0700

 Fix the backport test

Before enabling squashing commits, consider these disadvantages:

  • You lose information about when specific changes were originally made and who authored the squashed commits.
  • Some Git commands that use the "SHA" or "hash" ID may be harder to use since the SHA ID for the original commits is lost. For example, using git rerere may not be as effective.

For more information, see "Configuring commit squashing for pull requests."

Rebasing and merging your commits

You can also rebase your pull request's commits, which adds all commits from your topic branch (or head branch) onto the base branch individually without a merge commit. Pull requests with rebased commits are merged using the fast-forward option.

For a visual representation of git rebase, see The "Git Branching - Rebasing" chapter from the Pro Git book.

When you rebase your pull request's commits you simplify the history of your changes in Git. For more information about rebasing pull request commits, see the "Git rebase" chapter from the Pro Git book.

Before enabling commit rebasing, consider these disadvantages:

  • Repository contributors may have to rebase on the command line, resolve any conflicts, and force push their changes to the pull request's topic branch (or remote head branch) before they can use the rebase and merge option on GitHub. Force pushing must be done carefully so contributors don't overwrite work that others have based their work on. To learn more about when the Rebase and merge option is disabled on GitHub and the workflow to re-enable it, see "About pull request merges."

For more information, see "Configuring commit rebasing for pull requests."