Mailchimp Developer LogoMailchimp Developer Wordmark

Git Formatting Conventions

The basics

Git version control is how we work together as a team. Using standardized branch naming and commit message conventions helps us keep an easy-to-understand history of the changes in the project. We’ll also ask you to sign off on your contribution using the Developer Certificate of Origin with your name and your email address.

Naming Git branches

When you’re creating a branch, name it using following information:

  • The ID number of the GitHub issue

  • Your GitHub username

  • The slug

Use the following standard: 





Writing commit messages

You should make atomic commits based on the “conventional commit” standard, using the standard  type: subject. Use the following structure.   <type>[optional scope]: <description> [optional body] [optional footer(s)]

Supported  types include:



A new feature (this correlates with MINOR in Semantic Versioning)


A bug fix (this correlates with PATCH in Semantic Versioning)


Documentation only changes


Changes that do not affect the meaning of the code; for example, white-space, formatting, or missing semicolons.


A code change that neither fixes a bug nor adds a feature


A code change that improves performance


Adding missing or correcting existing tests


Changes to the build process or auxiliary tools and libraries such as documentation generation

Note the following conventions:

  • Use the imperative, present tense. For example, : use "change", not "changed" or "changes".

  • Messages should be all lowercase.

  • No dot (.) at the end.

  • Use BREAKING CHANGES only if your changes will break existing queries or schemashusky.


feat: add sendEmail() job docs: add doc for sendEmailJob() method refactor: combine all reducers into a single function BREAKING CHANGES: remove header template. To migrate to the React component, use HeaderComponent

You can see more examples on the conventional commit page.

The commit convention will be enforced via commit-lint and husky and you won't be allowed to add a commit that doesn't fit the convention. Check any error messages for specifics of how to reformat your commit to match the specification.

Signing-off on your contribution

We use the Developer Certificate of Origin (DCO) in lieu of a Contributor License Agreement for all contributions to Open Commerce open source projects. We request that contributors agree to the terms of the DCO and indicate that agreement by signing all commits made to Open Commerce projects by adding a line with your name and email address to every Git commit message contributed.

Use the standard Signed-off-by: Jane Doe <>

If you have your and set as part of your Git configuration, you can sign your commit automatically with Git by using git commit -s i.

By signing your commit you are certifying that you have the right to submit it under the open source license used by that particular Open Commerce project. You must use your real name (no pseudonyms or anonymous contributions are allowed.)

We use the Probot DCO GitHub app to check for DCO sign-offs of every commit. If you forget to sign your commits, the DCO bot will remind you and give you detailed instructions for how to amend your commits to add a signature.