GIT HOOK to check keyword "PROMOTE" in message when GIT MERGE is executed

Question

I need to check for "PROMOTE" keyword in message whenever there is a merge with master and other branch

Eg: If the git command is:
git merge -m "MERGE COMMIT 1 FROM BRANCH1 TO MASTER" f145cd536463e595f1e4306eeec6f92a9cd6c734 The merge should exit with a error "PROMOTE key word not set in merge message"

git merge -m "PROMOTE COMMIT 1 FROM BRANCH1 TO MASTER" f145cd536463e595f1e4306eeec6f92a9cd6c734 The merge should be successful.

Answer 1

The problem with the merge command is that it is not guaranteed to create a commit unless you use --no-ff. For example you might get the following result from your command.

git merge  -m "MERGE COMMIT 1  FROM BRANCH1 TO MASTER"
Updating f145cd5..cd6c734
Fast-forward (no commit created; -m option ignored)

See this post and this PDF for a great explanation of fast-forward vs no fast-forward when merging. Some people think -no-ff muddies history and it definitely breaks git-bisect and git blame. However others love --no-ff because it allows merge comments and visualization of what happened in a feature branch.

If you decide to use --no-ff, you can configure git to to only do --no-ff globally or on a per branch basis. Use this command to configure --no-ff on master only.

git config branch.master.mergeoptions  "--no-ff"

Let's get back to your original problem.

Git supports hooks that can be used for verification and work flow. Hooks can be run at the local client or server where developers push changes. A regular expression using the client hook commit-msg, like this one, seems perfect. However git does does not have a pre-merge hook that you could use to reject the merge. See here for a list of hooks and their triggering commands. Even worse you will notice that the git merge does not trigger any of the hooks even if you force a commit with --no-ff.

So you have two choices. They are the same as those mentioned in this post which explores the topic even further with no better solutions.

• Put an update hook, like this one, on a git server where developers are pushing. The problem with this approach is it doesn't keep them from making bad comments. This approach just keeps bad comments off the server. Developers will have to do a lot of work in fixing the history before they can push to the server if they don't do it right the first time.
• Write (and distribute, and maintain...) a git-merge wrapper which will do that control at the local repo level. Michael J Gruber has a pre-merge hook in his git fork here.