Introduction

When Git stops on a merge conflict, it already prepares a default merge commit message for you. If you want to keep that generated message, the key is simple: finish resolving the merge and commit without supplying your own -m message.

How Git Stores the Default Message

During a merge conflict, Git writes a prepared message into its merge state. After you resolve conflicts and stage the files, a normal git commit uses that prepared merge message as the starting point in your editor.

A typical workflow looks like this:

1git merge feature-branch
2
3# resolve conflicts in your editor
4
5git add path/to/resolved-file
6git add another/resolved-file
7git commit

At the git commit step, Git opens your editor with the generated merge message. You can keep it, edit it, or save it unchanged.

Use the Default Message Without Opening an Editor

If you want Git's generated message exactly as-is, use:

git commit --no-edit

This tells Git to reuse the prepared merge message and skip the editor entirely. It is the most direct answer to "use Git's default commit message when resolving merge conflicts."

What Not to Do

If you run:

git commit -m "fixed merge"

you replace the prepared merge message with your own text. That is fine if you want a custom message, but it is not how you keep Git's default one.

Likewise, if conflicts are not fully resolved or staged, Git will refuse to create the merge commit. The prepared message exists, but the merge cannot finish until the index is clean enough.

Check Merge Status Before Committing

A quick git status helps confirm what is still unresolved.

git status

You want to see that all conflicted files have been fixed and staged. If Git still reports "both modified" or "unmerged paths," you are not ready for the final commit yet.

Why the Default Message Can Be Useful

Git's generated merge message already includes the context of the merge, usually something like merging one branch into another. For routine merges, that is often enough. It preserves the fact that this was a merge commit rather than a normal single-parent commit.

Many teams are happy with the default message because:

• it is consistent
• it records the source branch
• it avoids unnecessary hand-written noise

If the conflict resolution involved a notable decision, you can still open the editor with plain git commit and add a short explanation below the generated first line.

Merge Commit Versus Rebase Conflict

Be careful not to mix this up with rebase conflicts. A merge conflict during git rebase uses different continuation commands and a different state machine. The idea of a prepared message still exists in Git workflows, but the command you run to continue is not the same.

This article is specifically about merge conflicts that end in a merge commit.

Common Pitfalls

• Using git commit -m ... and accidentally overriding the generated merge message.
• Forgetting to stage the resolved files before committing.
• Assuming git commit --no-edit can work while unmerged paths still exist.
• Confusing a merge conflict with a rebase conflict and using the wrong continuation flow.
• Editing the merge message template carelessly and deleting useful context about the merged branch.

Summary

• After resolving conflicts, stage the files and run git commit to use Git's prepared merge message.
• Use git commit --no-edit if you want the default message unchanged.
• Do not pass -m if your goal is to keep Git's generated message.
• Check git status first to make sure all conflicts are resolved.
• The default merge message is often sufficient and preserves useful context automatically.