- Describe why a change is being made.
- How does it address the issue?
- Do not assume the reviewer understands what the original problem was.
- Do not assume the code is self-evident/self-documenting.
-
Capitalize the commit message
- This is as simple as it sounds. Begin all subject lines with a capital letter.
- For example:
Fix typo in User model
- Instead of:
fix typo in user model
- For example:
- This is as simple as it sounds. Begin all subject lines with a capital letter.
-
Do not end the subject line with a period
- Trailing punctuation is unnecessary in subject lines.
- For example:
Refactor error handling
- Instead of:
Refactor error handling.
- For example:
- Trailing punctuation is unnecessary in subject lines.
-
Describe what was done
- Don't write a git commit subject line that talks about what you did, or what you are doing.
- For Example:
Fixed onboard page swipe crash
-- Don'tFixing onboard page swipe crash
-- Don'tFix onboard page swipe crash
-- Do
- A properly formed Git commit subject line should always be able to complete the following sentence:
- If applied, this commit will your subject line here:
- If applied, this commit will
fix onboard page swipe crash
- If applied, this commit will
remove deprecated methods
- If applied, this commit will
- Notice how this doesn’t work for the other non-imperative forms:
- If applied, this commit will
fixing onboard page swipe crash - If applied, this commit will
removed deprecated methods
- If applied, this commit will
- If applied, this commit will your subject line here:
-
The commit body must not contain more than 72 characters per line.
-
The commit subject or body must not contain Emojis.
- The change is as small as possible.
- The MR must include Before and After screenshots if UI changes are made.
- Clear title and description explaining the relevancy of the contribution.
- Description includes any steps or setup required to ensure reviewers can view the changes you’ve made (for example, include any information about feature flags).
- Always review code before committing it
- Name your sub branches by convention
- Use a consistent naming convention for your feature branches to identify the work done in the branch.
- These are all good branch names:
- add-author-profile - feature/app-analytics - bug/profile-button-editing