You can allow contributors with push access to your repository to merge their pull requests on your GitHub Enterprise instance 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 your GitHub Enterprise instance to meet your workflow needs and preferences for managing Git history. You can enforce one type of merge method, such as commit squashing by only enabling the desired method for your repository.
When you click the default Merge pull request option on a pull request on your GitHub Enterprise instance, all commits from the feature branch are added to the base branch in a merge commit. The pull request is merged using the
To merge pull requests, you must have write permissions in the repository.
Squashing your merge commits
When you select the Squash and merge option on a pull request on your GitHub Enterprise instance, the pull request's commits are squashed 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 and merged into the default branch. Pull requests with squashed commits are merged using the fast-forward option.
You can use squash and merge to create a more streamlined Git history in your repository. Work-in-progress commits are helpful when working on a feature branch, but they aren’t necessarily important to retain in the Git history. If you squash these commits into one commit while merging to the default branch, you can retain the original changes with a clear Git history.
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 rereremay not be as effective.
For more information, see "Configuring commit squashing for pull requests."