From f9d9144e3de5b8b7948239b112b60f0b17a184d7 Mon Sep 17 00:00:00 2001 From: Pierre Vanduynslager Date: Mon, 11 Jun 2018 11:32:14 -0400 Subject: [PATCH] docs: Add a troubleshooting section about squashed commits --- docs/support/troubleshooting.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/support/troubleshooting.md b/docs/support/troubleshooting.md index e1e2594a..80823a6a 100644 --- a/docs/support/troubleshooting.md +++ b/docs/support/troubleshooting.md @@ -44,3 +44,13 @@ npm ERR! You do not have permission to publish "". Are you logged This message is a little unclear, and might not have anything to with your `NPM_TOKEN` or authentication method. It might instead be related to the package name itself. If there is already a package with the same name as yours or, there is a very close match, it could trigger this error. Best way to be sure, is to search [npmjs.org](https://www.npmjs.com/)) using your package name. If there is a name conflict, rename your package in your `package.json` + +## Squashed commits are ignored by **semantic-release** + +**semantic-release** parses commits according to a [commit message convention](https://github.com/semantic-release/semantic-release#commit-message-format) to figure out how they affect the codebase. Commits that doesn't follow the project's commit message convention are simply ignored. + +When [squashing commits](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing) most Git tools will by default generate a new commit message with a summary of the squashed commits. This commit message will most likely not be compliant with the project's commit message convention and therefore will be ignored by **semantic-release**. + +When squashing commits make sure to rewrite the resulting commit message to be compliant with the project's commit message convention. + +**Note**: if the resulting squashed commit would encompasses multiple changes (for example multiple unrelated features or fixes) then it's probably not a good idea to squash those commits together. A commit should contain exactly one self-contained functional change and a functional change should be contained in exactly one commit. See [atomic commits](https://en.wikipedia.org/wiki/Atomic_commit).