From 48c0e31ea96c355d137a1131033cc0f356672a3e Mon Sep 17 00:00:00 2001 From: Bryan Dady Date: Fri, 10 Sep 2021 23:36:10 -0600 Subject: [PATCH] Address typos and layout Resolve some minor typos and line up long line wrap point --- docs/tutorials/writing_commits.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/docs/tutorials/writing_commits.md b/docs/tutorials/writing_commits.md index cf6b6bda11..4cf377a8c1 100644 --- a/docs/tutorials/writing_commits.md +++ b/docs/tutorials/writing_commits.md @@ -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 @@ -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 ` - **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 | | ---- | ------ |