...
Define repository settings in .github/settings.yml so that they can be managed and tracked via pull requests, see Fabric example.
Use recommended repository settings as a starting point, e.g. Repository options, Branch protection rules (TBD by TOC and Hyperledger staff)
- Consider using a CODEOWNERS file to specify write permission per directory, see Fabric example with additional /docs maintainers.
- Consider using a PULL_REQUEST_TEMPLATE.md and ISSUE_TEMPLATE
GitHub workflow
- Rebase merging is preferred over Merge commits and Squash merging to keep commit history and PR description clean (assuming contributors squash/amend their own pull requests)
- Opinion or best practice?
Although there are often multiple paths to achieve an outcome in git and GitHub, there is value in defining a suggested path, both for the benefit of new GitHub users, and for the sake of project consistency.
Examples
- Rebase merging is preferred over Merge commits and Squash merging to keep commit history and PR description clean (assuming contributors squash/amend their own pull requests)
amend commits instead of squashing commits - "git commit --amend"
Mergifyio to simplify cherry picks and backports - "@Mergifyio backport <branch>"
Example guidance for forking, branching, remotes, creating pull requests, updating pull requests, cherry picking - https://hyperledger-fabric.readthedocs.io/en/latest/github/github.html