Gerrit/Commit message guidelines

The commit message of your change plays an important role. It is first thing other people will see about your change.

component: Short subject line

More details. The blank line between the subject and body is
mandatory. The subject line is used to represent the commit in
code-review requests, search results, git rebase, logs, and more.

Bug: T54321



The first line of the commit message is known as the subject. The subject should be less than 80 characters long (aim for 50-70).

  • Summarize your change in the subject line. Keep in mind that this will be in the repository forever.
  • Use the imperative mood in your subject line.
    The imperative mood sounds like you are giving instructions to someone, and might start with words like "Change", "Fix", "Add", "Remove", "Document", "Refactor", etc.
    Good examples are "Add Badge::query to query the API" , "Avoid API query in SimpleBadge", and "Support zeroes in SimpleBadge::add".
    Bad examples would be "Added Badge::query method", "Fixed Badge::query method", "Badge can query the API", "Badge doesn't do API queries", or "Zeroes work when adding badges".
  • Your subject line should be short, clearly state what your commit is changing. It should not be possible to use the same subject line for two commits that do different things. People will read your subject line out of context, as it passes by in change feeds, code review emails, git-blame logs, release notes, deployment changelog, etc. A good subject line helps decide quickly whether this commit among many will be relevant to a given interest or concern.
    Good examples: "badger: Add accessibility labels to form fields", "rdbms: Avoid infinite loop on null input", and "htmlform: Change colours to match April 2020 design".
    Bad examples: "Implement accessibility fixes", "Don't crash", or "Make prettier with a better design".
  • Do not end the subject line with a period/full stop/dot (.).
  • Optionally, prefix the subject with the relevant component. A component is the general area that your commit will change.


When writing the body text, think about the following questions:

  • Why should this change be made? What is wrong with the current code?
  • Why should it be changed in this way? Are there other ways?
  • Did you consider other approaches? If so, describe why they were not as good.
  • How can a reviewer test or verify that your code is working correctly?


  • … separate the body from the subject with one empty line.
  • … wrap the message so that lines are a maximum of 100 characters long. Many editors/tools can do this automatically; 72 characters is a common width to wrap at. However, do not break URLs to make them 'fit', as this will make them un-clickable; keep them, even if they are longer.
  • … refer to other commits by using a (short) Git commit hash if they are merged. If they are not yet merged, refer to them by using their Gerrit Change-Id.


  • … refer to other commits with a Gerrit URL.
    Instead, use the Git commit hash. This allows easy navigation of the Git repository when offline. It also allows users of all repository viewers (Gerrit, Gitiles, Phabricator, GitHub, and local Git interfaces) to automatically navigate to other commits within the same interface. A URL can only be resolved when online and using Gerrit, which breaks the ability for people to navigate quickly.
  • … use a URL as the only explanation for a change.
    If the change is justified by discussions elsewhere or external documentation, then briefly summarise the relevant points in the commit message.

Footer and meta-dataEdit

The most important information of the footer is the Change-Id (mandatory) and Bug.

Format "Bug" and "Change-Id" meta-data exactly like in the examples below, and place them together at the end of the body, after one empty line.

Find more information on individual meta-data fields below.


Good exampleEdit

jquery.badge: Add ability to display the number zero

Cupcake ipsum dolor sit. Amet tart cheesecake tiramisu chocolate cake
topping. Icing ice cream sweet roll. Biscuit dragée toffee wypas. 

Does not yet address T44834 or T176. Follow-up to Id5e7cbb1.

Bug: T42
Change-Id: I88c5f819c42d9fe1468be6b2cf74413d7d6d6907

Bad exampleEdit

Improved the code by fixing a bug.

Changed the files a.php and b.php

Bug: T42
Change-Id: I88c5f819c42d9fe1468be6b2cf74413d7d6d6907

Additional informationEdit


Most programs we use that display Git commit, render the subject line as plain text. This means URLs do not work, and selecting/copying of text often is not possible. Therefore, do not mention Phabricator tasks, Git commits, or urls inside the subject line. Instead, mention those in the body text, or footer meta-data. That way, they can be universally selected, copied, or clicked.


You may start the subject line with a component, which will indicate what area of the project is changed by your commit.

It should be one of the following:

  • A directory of PHP classes under includes/ or includes/libs, such as "installer", "jobqueue", "objectcache", "resourceloader", "rdbms", etc.
  • A PHP class name, such as "Title", "User", "OutputPage", etc.; typically for classes without subdirectory in includes/.
  • ResourceLoader module name (like "mediawiki.Title", "mediawiki.util", etc.).
  • Generic keyword affecting multiple areas relating to the type of change, such as:
    • "build" - for changes to files relating to the development workflow, such as updates to package.json, .travis.yml, etc.
    • "tests", "qunit", "phpunit" - for changes that only affect unit or integration test suites, or the test suite runners.


To reference a Phabricator bug or task, in the commit message mention it inline using the Txxx notation (e.g. "That was caused by T169.")

To express that a commit resolves (even partially) or is specially relevant to a bug, add Bug: Txxx in the footer at the end of the commit message.[1] (If you're amending a commit message, insert it immediately above the Change-Id: line, without an empty line between them. Remember to follow the overall structure rules and separate the body from the subject with one empty line.)

Bug: T169

A bot will automatically leave a comment on the Phabricator task about any significant events (being merged, abandoned, etc.). If a patch resolves two or more bugs, put each Bug: T12345 reference on its own line at the bottom.

Bug: T299087
Bug: T299088


Whenever you refer to another commit, use the SHA-1 git hash of the merged commit. If the commit in still pending review, use the Gerrit Change-Id hash instead of the git hash because the hash relates to an individual patch set (which changes when rebased, thus creating a dead-end).


Gerrit 's git-review tool will automatically append the "Change-Id: Ixxx" keyword to new commits.


Depends-Onː Ixxx

If you have cross-repo dependencies (your commit depends on another commit in a different repository), declare them by adding Depends-On: Ixxx... to the last paragraph. ("Ixxx"... is the Change-Id of the other commit.) This will instruct Zuul to test the commit together with that one.

Crediting othersEdit

Co-Authored-byː gerrit_username <>

Add this line before the Change-Id to credit other developers working on the change. You can add more than one separated by a line break.

Note that unlike other words in commit message footers, the word by is not capitalized; it's Co-Authored-by, not Co-Authored-By.

Further readingEdit


  1. As with all headers/footers, write the name with words individually capitalized, with hyphens between (e.g. Hypothetical-Header-Or-Footer). Follow the name with a colon (":"), then one space. Similar to the Git commit, HTTP and Email headers, adding extra blank lines above the footer would cut off the footer and wrongly include the former part in the body.