You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To ensure that reviewers can understand commit messages and pull requests quickly, guidelines on their formats and content should be established and documented accordingly.
For commit messages, How to Write a Git Commit Message is a blog post that discusses what I consider good guidelines for commit messages:
Separate subject from body with a blank line
Limit the subject line to 50 characters
Capitalize the subject line
Do not end the subject line with a period
Use the imperative mood in the subject line
Wrap the body at 72 characters
Use the body to explain what and why vs. how
Additionally, the blog post also provides an example of a commit message that lists resolved and related issue numbers at the bottom:
Resolves: #123
See also: #456, #789
Commit 042edf7 is an example of what I would consider an ideal commit message format.
For pull requests, it is important to provide a big-picture overview of what the pull request is doing in the first comment. For pull requests related to the frontend, it is also valuable to provide screenshots of new or updated UI. The first comment of #45 is what I would consider an ideal example of both of these principles.
The text was updated successfully, but these errors were encountered:
To ensure that reviewers can understand commit messages and pull requests quickly, guidelines on their formats and content should be established and documented accordingly.
For commit messages, How to Write a Git Commit Message is a blog post that discusses what I consider good guidelines for commit messages:
Additionally, the blog post also provides an example of a commit message that lists resolved and related issue numbers at the bottom:
Commit 042edf7 is an example of what I would consider an ideal commit message format.
For pull requests, it is important to provide a big-picture overview of what the pull request is doing in the first comment. For pull requests related to the frontend, it is also valuable to provide screenshots of new or updated UI. The first comment of #45 is what I would consider an ideal example of both of these principles.
The text was updated successfully, but these errors were encountered: