-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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 FXIOS-{issue-number} [version-number] Short summary
For example Add FXIOS-9000 [v101] New Nimbus manager added
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. |
| Refactor | An update to existing code and/or refactoring. |
| Bugfix | Fix an issue e.g. bug, typo, accident, misstatement. |
| Bump | Increase the version of something e.g. dependency. |
| Build | Change only to the build process, tooling, or infra. |
| Document | A change to documentation only. |
| Localize | String and localization only related changes. |
| Revert | Reverting a previous commit. |
Discussion: Why the standard GitHib
Fixes/Fixkeyword is not used? Simply put, these two keywords close tickets. However, we want to prevent tickets from being closed - rather, those tickets should follow our process and be moved to QA. As such, we useBugfixinstead.
Following the keyword is the issue number - this is the issue the ticket addresses. It is formatted as: FXIOS-XXXX where XXXX is the ticket number from JIRA. Note: we should use the format prefix FXIOS-. We use the JIRA number as a standard because JIRA is the source of truth. While contributors might use the GitHub number for issue, when we merge their tickets, we should still enter the appropriate JIRA ticket ID.
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 - whether enabled for users or not. This will allow easy identification of when/in what version something may have been introduced. The version number is only for GH purposes. For releases of features and such, JIRA remains the source of truth.
For branches meant for dot releases, or branches meant to be backported, the same rule of "mark it as the version the code went into production" applies. So, if main is on v123, but we're making a fix meant for v122, the PR would be marked v122 when being merged to main
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.