...
Define repository settings in .github/settings.yml so that they can be managed and tracked via pull requests, see Fabric example.
Define Branch protection rules (TODO - define best starting config)
- Add screenshot
- Reusable github actions
- Consider using a CODEOWNERS file to specify write permission per directory, see Fabric example with additional /docs maintainers.
- Add a link to maintainers.md scope field so that users can find domain area contacts
- Consider using a .github/PULL_REQUEST_TEMPLATE.md and .github/ISSUE_TEMPLATE
...
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.
- 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)
- Preserve commit hash - rebase then merge with fast forward option
- git rebase (branch); git merge --ff-only
- git commit -s versus git commit -S
- -S is crypto verified, -s is DCO signoff. Rebase preserves both.
- amend commits to avoid having multiple commits (amend commits instead of squashing commits -
git commit --amend). If you do have multiple commits squash them before opening PR. Keep pull requests focused to a logical unit of work. - Mergify to simplify cherry picks and backports -
@Mergifyio backport <branch> - Example Fabric guidance doc for forking, branching, remotes, creating pull requests, updating pull requests, cherry picking
- TODO add this to Hyperledger TOC best practices site instead of buried in Fabric docs, add a link to Git-help Discord channel for git/github questions and discussions