Details
-
Task
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
None
-
None
Description
In order to enforce certain restrictions for specific branches, GitHub provides the concept of 'branch protection'. Such restrictions can take many forms, for example enforcing a linear history or requiring specific GitHub actions to pass before allowing a pull-request to merged on the branch.
I would suggest also creating such restrictions for the master branch of both the main JDO and the JDO site repository. My suggested rules are as follows:
- Require a linear history – This will disallow merge commits on the branch. As a result
- pushes to the protected branch containing a merge commit will be rejected by the repository. This will most likely only apply to GitHub and not GitBox, so pushing a merge commit to a protected branch through GitBox will most likely break the mirror. I would recommend against it.
- the option "Create a merge commit" to merge a pull request for this branch is disabled.
- pull-requests for this branch containing a merge commit can only be merged using the "Squash and merge" option to remove this merge commit in the process.
- Require status checks before merging – This will require the selected status checks (i.e. GitHub actions) to pass before the pull requests for this branch can be merged.
- Require branches to be up-to-date – This will require a PR to always be up-to-date with its base branch. This is a sub-option of "Require status checks" and is meant as a way to enforce that the checks are always run on the current version of the base branch. This ensures that a combination of new commits on the master and the commits of the pull request create a build failure which is not visible with either of the two separately.
As requiring branches to be up-to-date creates the most overhead when there are frequent other activities on the repository, this requirement should be considered carefully. Especially with long-running checks, always having to rebase pull-requests on the current master before being able to merge them can be cumbersome.
Another possible option would be requiring approvals (of members with write access) before a pull request can be merged. I did not suggest this by default as this rule is binding since none of us have administrative privileges on the repository. As a result, it would be impossible to create a pull requests for a trivial fix and merge it without any approval. (This restriction does not apply to direct pushes to the branch.)
Lastly, as merge commits are not desired and are generally disallowed by the branch protection rule, I would suggest to completely disable the option to create a merge commit when merging a pull request.