In git 1.7.10, the git developers decided merge commits could be made too easily. As explained in this blog post, forcing the interactive commit message behavior should make those commit messages more detailed and could reduce the overall frequency of unnecessary merges.

You can use the --no-edit flag to avoid this behavior, but, well, don't. Merge commits, like any commits to history, should be well constructed. Your history should be nothing but useful.

You can't provide your own message, but the --no-edit option passed to git pull will auto-generate merge messages.

git pull --no-edit

So I need to change my merge commit message produced by git pull to another message.. Is it possible?

Yes. After the pull, if a merge commit was created, say

git commit --amend

You will be asked for a replacement commit message.

However, you should have done this together with the pull, by saying

git pull --edit

And yes, I know that git pull is a shorthand for git fetch and git mergeI read from another similar question on SO but I just can't grasp that

Grasp it. You never need to say pull; it is confusing and dangerous. To merge master into the branch you are on, say

git fetch
git merge origin/master 

Again, to avoid having to rewrite the commit message later, say

git fetch
git merge --edit origin/master 

You asked: "What is the safest command to fetch and merge with custom message?" That.

(It is also possible to configure your Git so that a merge commit always offers you the chance to edit its message. I prefer it that way. Recent Git versions are set up this way by default; you might be using a somewhat outdated Git, else the problem would never have arisen.)

So I would be thankful if anyone knows how I can solve this.

The first question to answer here is: Which commit(s) do you want to look at? Only the head commit of the pull request branch? All commits on the branch (which could be many)?

github.event.pull_request.head.sha should give you the ID of the head commit, github.event.pull_request.base.sha that of the base (target) branch (in case you want to look at all commits).

Note that you'll have to tell actions/checkout to download more than the latest commit if you want to inspect those, or fetch the relevant part of history in your workflow. The triggering commit for pull_request events is a temporary merge commit, so it's none of your commits. 😉

From Git Documentation:

Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD

As to your question about: WHY

1. Why is Git creating a MERGE commit: That is the default behavior of git pull. There are lots of explanation of this behavior on the internet, this does a good job of explaining it.
2. Why is Git asking for a commit message now: Three possible options come to my mind:
   • You updated your git client
   • You never had a local branch which was ahead of the remote before
   • Your git config was changed recently

How to avoid this:

Since your local repository is 1 commit ahead, git tries to merge your remote to your local repo. This can be handled via merge, but in your case, perhaps you are looking for rebase, i.e. add your commit to the top. You can do this with

git rebase or git pull --rebase

If this is indeed the behavior you are looking for, you can setup your git config to make rebase a default option for your git pull

Set it up globally with:

git config branch.autosetuprebase always # Force all new branches to automatically use rebase

Or you can set it up per branch:

git config branch.*branch-name*.rebase true # Force existing branches to use rebase.

This is depend on the editor you're using.

If vim you can use ESC and :wq or ESC and Shift+zz. Both command save file and exit.

You also can check ~/.gitconfig for editor, in my case (cat ~/.gitconfig):

[user]
    name = somename
    email = [email protected]
[core]
    editor = vim
    excludesfile = /home/mypath/.gitignore_global
[color]
  ui = auto
  # other settings here