Skip to content

docs: tutorial - address typos and layout #419

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 11, 2021
Merged

docs: tutorial - address typos and layout #419

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 11 additions & 8 deletions docs/tutorials/writing_commits.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,20 +1,21 @@
For this project to work well in your pipeline, a commit convention
must be followed.
For this project to work well in your pipeline, a commit convention must be followed.

By default commitizen uses the known [conventional commits][conventional_commits], but you can create
your own following the docs information over [customization][customization].
By default commitizen uses the known [conventional commits][conventional_commits], but
you can create your own following the docs information over at
[customization][customization].

## Conventional commits

If you are using [conventional commits][conventional_commits], the most important
thing to know is that you must begin your commits with at least one of these tags: `fix`, `feat`. And if you introduce a breaking change, then, you must
thing to know is that you must begin your commits with at least one of these tags:
`fix`, `feat`. And if you introduce a breaking change, then, you must
add to your commit body the following `BREAKING CHANGE`.
Using these 3 keywords will allow the proper identification of the semantic version.
Of course, there are other keywords, but I'll leave it to the reader to explore them.

## Writing commits

Not to the important part, when writing commits, it's important to think about:
Now to the important part, when writing commits, it's important to think about:

- Your future self
- Your colleagues
Expand All @@ -27,8 +28,10 @@ understand what happened.
- **Keep the message short**: Makes the list of commits more readable (~50 chars).
- **Talk imperative**: Follow this rule: `If applied, this commit will <commit message>`
- **Think about the CHANGELOG**: Your commits will probably end up in the changelog
so try writing for it, but also keep in mind that you can skip sending commits to the CHANGELOG by using different keywords (like `build`).
- **Use a commit per new feature**: if you introduce multiple things related to the same commit, squash them. This is useful for auto-generating CHANGELOG.
so try writing for it, but also keep in mind that you can skip sending commits to the
CHANGELOG by using different keywords (like `build`).
- **Use a commit per new feature**: if you introduce multiple things related to the same
commit, squash them. This is useful for auto-generating CHANGELOG.

| Do's | Don'ts |
| ---- | ------ |
Expand Down