-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Pull Request Naming Guide
The name of a PR is important, because it will eventually become the commit that shows up in main. Here are the guidelines for how to name a PR.
Anatomy of a PR name:
Keyword #issue-number [version-number] Short summary
The keyword should be the first thing in the name, to let everyone know what kind of change the PR is. Here is a table of the standard keywords, and what they mean:
| Key Word | Meaning |
|---|---|
| Add | Create a capability e.g. feature, test, dependency. |
| Remove | Remove a capability e.g. feature, test, dependency. |
| Fix | Fix an issue e.g. bug, typo, accident, misstatement. |
| Bump | Increase the version of something e.g. dependency. |
| Make | Change only to the build process, tooling, or infra. |
| Refactor | A code change that is just refactoring. |
| Document | A change to documentation only. |
| Localize | String and localization only related changes. |
Following the keyword is the issue number - this is the GitHub issue the ticket addresses. It is formatted as: #XXXX where XXXX is the ticket number. This will allow GitHub to automatically link to the issue, making it easier to find information.
After the issue number, we list the version number. Generally, the version number will always be included, and will refer to the version in which the commit will ship for users.
The only time where this version number may be omitted is in the case where a feature is added to main but is not shipping in a known version. However, this should generally be a rare case.
This is a short summary of what your commit is doing.
Firefox-iOS uses a Squash & Merge policy which results in your entire PR being a single commit on the main commit history.