3

While merging master into the current branch before a push if its not a fast-forward merge, git sets a default message Merge branch 'master' into YOUR-BRANCH-NAME.

But to make the git history more meaningful, what would be a standard message format for merge commits? Using the default message doesn't make much sense because the branch names would be random all the time(Branching strategy: GitHub flow).

beginer
  • 188
  • 1
  • 11
  • If you are directly pushing `YOUR-BRANCH-NAME` to `master` without creating a PR, I think it's better to do `git pull origin -r master` instead of `git pull origin master` before push. With `-r` or `--rebase`, no merge commit is created. – ElpieKay Apr 10 '19 at 03:45
  • I'm voting to close this question as off-topic because the question is unclear and asks about a too broad strategy for naming the commits, while not providing any desired goal and not clarifying what's wrong with the current behavior. – Andrey Tserkus Apr 10 '19 at 04:04
  • @ElpieKay I create merge requests(PR). – beginer Apr 10 '19 at 05:10

1 Answers1

4

You would need a dedicated function in order to get a custom merge message each time you merge one branch to another.
But after a git pull, only git commit --amend -m "new message" would change said message. You might be able to automate it in a post-merge hook.

But again, if you can avoid a pull-merge, and use a pull-rebase instead (for commits not yet pushed), that can be better: see git config pull.rebase true in order to be able to use git pull as you do today, but with a rebase instead of a merge.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • thank you so much for the answer and supporting links, [git config pull.rebase true](https://stackoverflow.com/a/30209750/6309) would help me. – beginer Apr 10 '19 at 05:25