...
While this document and the others on our Wiki site provide a lot of great guidance to developers planning to make contributions to the project, we would ask that developers (and the maintainers/committers) of the project pay particular attention to the following "top 4" practices and adhere to them closely when working on project repositories.
1. Commit subject line messages should explain the problem that the commit is solving in 50 characters or less. “Fixing bug” or “adding comments” doesn’t explain the problem the commit is solving!.
2. Provide a message body to the commit to provide more detail explanation. When you do, keep lines in the body to 72 characters or less.
...
git commit –s –m “This is the subject; keep to 50 char” –m “This is the first line of the message body"$'\n'"This is the second line of the message body."$'\n'"Keep all message lines to 72 char.”
3. Commit your changes in logical chunks. Make it easier for the community to review, comment on, and accept your contribution. For example, create a separate commit for a big fix and an enhancement.
4. Rebase the upstream development branch into your topic branch. Do not merge master into your local PR branch (this is the lazy approach to dealing with committed code locally in a branch, and then realizing that your PR isn’t merge-able because HEAD has changed). See https://git-scm.com/book/en/v2/Git-Branching-Rebasing if you need more help.
...
- Be consistent. This is related to the workflow but also expands to things like commit messages, branch names and tags. Having a consistent style throughout the repository makes it easy to understand what is going on by looking at the log, a commit message etc.
- Test before you push. Do not push half-done work.
- Use annotated tags for marking releases or other important points in the history. Prefer lightweight tags for personal use, such as to bookmark commits for future reference.
- Keep your repositories at a good shape by performing maintenance tasks occasionally:
1. Commit subject line messages should explain the problem that the commit is solving in 50 characters or less. “Fixing bug” or “adding comments” doesn’t explain the problem the commit is solving!.
2. Provide a message body to the commit to provide more detail explanation. When you do, keep lines in the body to 72 characters or less.
...
git commit –s –m “This is the subject; keep to 50 char” –m “This is the first line of the message body"$'\n'"This is the second line of the message body."$'\n'"Keep all message lines to 72 char.”
3. Commit your changes in logical chunks. Make it easier for the community to review, comment on, and accept your contribution. For example, create a separate commit for a big fix and an enhancement.
4. Rebase the upstream development branch into your topic branch. Do not merge master into your local PR branch (this is the lazy approach to dealing with committed code locally in a branch, and then realizing that your PR isn’t merge-able because HEAD has changed). See https://git-scm.com/book/en/v2/Git-Branching-Rebasing if you need more help.