Ensure github PR squash merge commit comments contain issue ID

Question

How can I ensure commit comments from a github PR squash merge contains required text?

We use Jira + Github and if a use enters Jira issue IDs in commit comments t

Answer 1

If you're using GitHub Enterprise, you can set up a pre-receive hook to reject commits that don't have a JIRA ticket number in them.

Check out the example here:

#!/bin/bash
#
# check commit messages for JIRA issue numbers formatted as [JIRA-<issue number>]

REGEX="\[JIRA\-[0-9]*\]"

ERROR_MSG="[POLICY] The commit doesn't reference a JIRA issue"

while read OLDREV NEWREV REFNAME ; do
  for COMMIT in `git rev-list $OLDREV..$NEWREV`;
  do
    MESSAGE=`git cat-file commit $COMMIT | sed '1,/^$/d'`
    if ! echo $MESSAGE | grep -iqE "$REGEX"; then
      echo "$ERROR_MSG: $MESSAGE" >&2
      exit 1
    fi
  done
done
exit 0

Answer 2

The other approach* around this is to ensure that commit messages include the branch name, which in JIRA are most likely derived from the issue title.

To achieve this, coworkers have to include in their .git/hooks directory a file named commit-msg with the following contents :

#!/bin/bash
current_branch="$(git rev-parse --abbrev-ref HEAD)"
tmp=$(mktemp) || exit
echo "$current_branch $(cat "$1")" > "$tmp"
mv "$tmp" "$1"

Then when someone is committing on the feature branch ABC-1234-customers-cant-log-in, a commit command like this :

git commit -m "Awesome changes"

...will actually produce the following commit message :

ABC-1234-customers-cant-log-in Awesome changes

...and JIRA will then automatically detect it and link the commit to the issue, thus ensuring a reliable recap of commits on the JIRA issue page.

We've put this policy in place in my team and it has several advantages :

• no more forgetting JIRA issue numbers in commit messages
• gain of time
• slightly easier to parse commit messages when you need it

(As a sidenote, just in case, this automated beahviour can also be disactivated on demand, with git commit -n)

* (note that these two solutions are not mutually exclusive. In fact, you could very well want both, Adil's for remote repo integrity, and this one for local use efficiency)