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:
type-###-yourhandle-slug
Examples
feat-123-impactmass-permissions
fix-222-spencern-shopify-hooks
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:
| Type | Description |
|---|---|
feat | A new feature (this correlates with MINOR in Semantic Versioning) |
fix | A bug fix (this correlates with PATCH in Semantic Versioning) |
docs | Documentation only changes |
style | Changes that do not affect the meaning of the code; for example, white-space, formatting, or missing semicolons. |
refactor | A code change that neither fixes a bug nor adds a feature |
perf | A code change that improves performance |
test | Adding missing or correcting existing tests |
chore | 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.
Examples
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 <jane.doe@example.com>
If you have your user.name and user.email 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.