digitalroute / cz-conventional-changelog-for-jira

A commitizen adapter for the angular preset of https://github.com/conventional-changelog/conventional-changelog
MIT License
64 stars 63 forks source link

Merging from other branch clobbers commitizen comment #65

Open tquid opened 2 years ago

tquid commented 2 years ago

Hi, when devs at my outfit merge a branch into the working branch, they get the commitizen prompts as expected, but they end up with Merge branch <such-and-so> into <working branch> as the commit message anyway, obviating effort put into satisfying the interactive commit.

Is there some configuration I am doing incorrectly? I'm using Husky, if it matters. Here is the Husky config for prepare-commit-msg:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

exec < /dev/tty && npx cz --hook || true
juliuscc commented 2 years ago

Hi @tquid!

Context

Commitizen (together with this adapter) helps you write commit messages during a commit. In other words it replaces/wraps git commit and adds new commits to the git history. In practical terms this is what happens when you use commitizen:

  1. Prompt the user and generate a nicely formated commit message.
  2. Run git commit -m ${MESSAGE} where MESSAGE is the message generated in step 1.

Problem

What commitizen does not do:

When you do a git merge, you add a commit completely without using commitizen. You are not using the tool wrong, you are just not using the tool at all. The same goes for if you would run git commit -m "..." (if husky was not involved).

Solution

It is difficult to suggest a solution for your specific team, as it differs a lot. But here are some workflows that I have seen:

  1. Use commitlint with a custom config to take into account for JIRA-messages. It is quite easy to add a plugin that verifies that the subject contains a JIRA-issue (if you even require that).
    • You can run commitlint either locally with husky (husky/commit-msg) or as a CI-step (Jenkins, CircleCI, GitHub Actions, whatever)
  2. When you squash and merge a PR the commit messages will be ignored, so sometimes teams opt for always using rebase instead. My current team formats the squashed commit message nicely by ourselves but it depends on how strict the requirements are.
    • If you only have a single commit when you create the PR GitHub will automatically use that commit message for the PR description and title. Which is then suggested when you squash and merge.
    • Bitbucket does not use the PR title when you squash and merge.

I hope this answered some of your questions. If your team needs more training in Git or you need a review of your Git-workflows I provide those services.