Skip to end of metadata
Go to start of metadata


ONLY 1 JIRA issue per commit.

Think about this scenario: a developer performs a Commit for 1 new functionality and 4 bugs.

Then, here are the problems:

  1. It is difficult for the reviewer to understand which code relates to which issue.
  2. It takes the reviewer more time to review. You may even discourage the reviewer to look at the code submission.
  3. In case 1 bug is not properly fix, then the whole commit is rejected.


  • Self-commits are not allowed.
  • NEVER embed binary files including jar, war, tar, gz, gzip, zip in Gerrit


To submit code into Gerrit on an unfinished feature, multiple times to bring transparency and get early feedback , refer to "Submitting a Draft Feature"


The following is based on OPEN-O experiences and multiple references in the open source community.

There are tons of reasons on why it is essentials to write good commit messages. For the sake of keeping things short, here are 3 reasons:

  • ONAP is public, so everything you do is widely visible. As you are proud of your work, you want to make good impressions.
  • It speeds up the reviewing process.
  • It helps to write good Release Notes.

Which Commits would you rather read?

Commit Structure


To formulate good commit message focus is these 3 points:

  • Explain the What, the Why and the How.
    • What: Do not assume the code is self-evident/self-documenting. The commit message should have a clear statement as to what the original problem is.
    • Why: It may fix a bug, it may add a feature, it may improve performance, reliability, stability, or just be a change for the sake of correctness. Describe the overall code structure, particularly for large changes, but more importantly describe the intent/motivation behind the changes.
    • How: Describe how the problem being fixed. Describe any limitations of the current code. For short obvious patches this part can be omitted, but it should be a high level description of what the approach was.
  • Keep in mind than within a 3 months, you may have to review your own code.


  • Write the summary line and description of what you have done in the imperative mode, that is as if you were commanding someone. Start the line with a VERB  FixAddChange instead of Fixed, Added, Changed.
  • Always leave the second line blank.
  • Keep the summary line shorter than 50 characters.
  • Keep the body line around 72 characters. Make as much paragraph as you need.
  • One commit per change.
  • List THE issue addressed, (not a list of issues).


  • Don't terminate the summary line with a period - it's a title and titles don't end with a period.
  • Don't use ! or !! in the message. They are useless.
  • Don't provide the issue number in the summary. Use External Reference section to list the ONE Jira issue.
  • Don't mix two unrelated functional changes. Idea is to divide to conquer. Think about the reviewer who must desiccate with issues he faces. Think about how easy it will be in case you have to revert code.
  • Don't include whitespace changes together with code changes. Make 2 separate commits.
  • Don't include patch set-specific comments like "Patch set 2: rebased"

In case of wrong commit message

There is always a possibility to change to commit message before the code is merged.

You simply have to enter the command line: git commit --amend

This method is applicable only for the latest change.


How to Write a Git Commit Message. Very inspiring, I particularly like this sentence What may be a hassle at first soon becomes habit, and eventually a source of pride and productivity for all involved.
OpenStack Git commit Good Practices
Commit Message Good Practices
Writing Good Commit Messages
On Commit Message (Thanks Geora)



    1. In case of using 'git commit --ammend', does this command guarantee that the change will be pushed to gerrit after edit is complete or is "git review" required as the next command to execute?

      1. Yes, git review is required as the next command.

      2. 'git commit --amend' only modifies the local commit object. This isn't a gerrit specific command, it's a sub-command of git itself. So, yes, a 'git review' is required after the change.

  2. Hi, could we put a header like "[OOM-1]" in the commit comment - then we can track a set of commits more easily in git history.  Also some systems hyperlink these headers to the actual JIRA - this would also aide for cross-repo distributed commits - thank you /michael

    1. Hi,

      The commit header is limited to 50 characters, thus I would use that limited space to explain the goal of the commit.If someone needs more info he can dive into Jira.

      While performorfing the "git commit -s" cmd, git provides an opportunity to use the above external reference section to establish a link with Jira. You just need to enter the JIRA issue ID and Gerrit will create the hyperlink automatically (no need to enter the full url).

      1. Sounds good - will do on my next commit


        1. As of the August 10, 2017 TSC meeting JIRA issue ID's are required in the commit message. As Gildas Lanilis says, you shouldn't be putting the issue in the subject line. It's actually rather poor form. Instead the recommendation from LF Release Engineering is to put it into the message footer exactly like the graphic shows (in the 'External References') and without the [ ] surrounding it.

          For tracking related changes in Gerrit you should be using the same topic when needed as you can search topics in the Gerrit UI.

        2. The multi-line commit structure works very well - reviews are still referenced back to the JIRA



          and use a "git commit --amend" for reviews already in progress.