You basically have two option.

Easy solution: don't merge, Rebase
Rebase your branch on top of the main branch, resolve conflict, and then merge. As you'll have a straight history, you'll be able to fast-forward to merge and this won't create any merge commit.

git checkout feature
git rebase main
# Resolve conflict if there is
git checkout main
git merge feature

Second option: Rebase -i
You can edit your history after your merge (before you push to a remote). You can manage this with rebase interactive mode.

git checkout main
git merge feature
#You merge and resolve conflict
git rebase -i <sha of the commit before the merge>

Then you'll be taken into an interactive shell with the list of the commits, e.g.:

pick 73c991e Create progress bar module
pick b8a0b83 merge branch feature
pick 2120f47 Add user form
pick 70c55e4 Quiz prototype system

You just need to add squash or s instead of pick:

pick 73c991e Create progress bar module
pick b8a0b83 merge branch feature
s 2120f47 Add user form
pick 70c55e4 Quiz prototype system

This command would squash together b8a0b83 and 2120f47. The next step will be a commit text editor where you have both commit message combined, and it's now up to you to edit them correctly to only keep your original message.

The answer marked correct here did not work for me as after you quit the editor with wq or :q!, the file gets saved and the merge happens.

The alternative, I've found for now is to suspend the vim process by using a Ctrl + Z and then aborting the merge with a git merge --abort and then killing the background process (you'll see the PID when you do the Ctrl + Z)

Actually it's not an error! It means you should enter some message to mark this merge.

My OS is Ubuntu 14.04. If you use the same OS, you just need to do this as follows:

1. Type some message

2. CtrlCO

3. Type the file name (such as "Merge_feature01") and press Enter

4. CtrlX to exit

Now if you go to .git and you will find the file "Merge_feature01", that's the merge log actually.

Looks like as of version Git 1.7.8 you can do git merge --edit ... to specify the commit message.

And as of 1.7.10, dropping into edit mode will be the default behavior

From this release on, the "git merge" command in an interactive session will start an editor when it automatically resolves the merge for the user to explain the resulting commit, just like the "git commit" command does when it wasn't given a commit message.

(though I'm not seeing it on in msysgit on windows).

Note that, starting git1.7.9.6 (and git1.7.10+), git merge itself will always trigger the editor, for you to add details to a merge.

"git merge $tag" to merge an annotated tag always opens the editor during an interactive edit session. v1.7.10 series introduced an environment variable GIT_MERGE_AUTOEDIT to help older scripts decline this behaviour, but the maintenance track should also support it.

It also introduces an environment variable GIT_MERGE_AUTOEDIT to help older scripts decline this behavior.

See "Anticipating Git 1.7.10":

Recently in a discussion on the Git mailing list, Linus admitted (and I agreed) that this was one of the design mistakes we made early in the history of Git.
And in 1.7.10 and later, the git merge command that is run in an interactive session (i.e. both its standard input and its standard output connected to a terminal) will open an editor before creating a commit to record the merge result, to give the user a chance to explain the merge, just like the git commit command the user runs after resolving a conflicted merge already does.

Linus said:

But I don't really care deeply how it actually works - my main issue is that git makes it way too easy to have bad merge messages.
I think part of that is an even simpler idiocy: we never even fire up the editor by default for a "git merge", but we do for a "git commit".
That was a design mistake, and it means that if you want to actually add a note to a merge, you have to do extra work. So people don't.

Note that, before Git 2.17 (Q2 2018), "git rebase -p" mangled log messages of a merge commit, which is now fixed.

See commit ed5144d (08 Feb 2018) by Gregory Herrero (``).
Suggested-by: Vegard Nossum (vegard), and Quentin Casasnovas (casasnovas).
^{(Merged by Junio C Hamano -- gitster -- in commit 8b49408, 27 Feb 2018)}

rebase -p: fix incorrect commit message when calling git merge.

Since commit dd6fb00 ("rebase -p: fix quoting when calling git merge", January 2018, Git 2.16.0-rc2), the commit message of the merge commit being rebased is passed to the merge command using a subshell executing 'git rev-parse --sq-quote'.

Double quotes are needed around this subshell so that, newlines are kept for the git merge command.

Before this patch, following merge message:

"Merge mybranch into mynewbranch

Awesome commit."

becomes:

"Merge mybranch into mynewbranch Awesome commit."

after a rebase -p.

With Git 2.23 (Q2 2019), A "merge -c" instruction during "git rebase --rebase-merges" should give the user a chance to edit the log message, even when there is otherwise no need to create a new merge and replace the existing one (i.e. fast-forward instead), but did not.
Which has been corrected.

See commit 6df8df0 (02 May 2019) by Phillip Wood (phillipwood).
^{(Merged by Junio C Hamano -- gitster -- in commit c510261, 13 Jun 2019)}