That's a default merge commit message. It doesn't take anything special to get it - just do any nontrivial merge into master:

- o - o - X (master)
   \     /
    o - o (topic)

The default commit message for commit X will be "Merge branch 'topic'". If you merge into a branch other than master, the default message is "Merge branch '<merged-branch>' into '<branch>'".

I'm not sure why you're asking about "fixing" and "avoiding" this. It's a very reasonable default message for a merge commit. If you'd like a more detailed merge commit message, you're certainly welcome to provide one. (The two primary ways are to use git merge --no-commit followed by git commit, or git merge followed by git commit --amend to edit the message.)

Perhaps you're used to doing only fast-forward merges? (Those are trivial merges, where the commit you're merging has your current branch as ancestor, so all git has to do is move the branch forward through history.) Those don't generate merge commits, so there's no commit message.

(By the way, pushing has nothing to do with this - all it does is copy information from one repo to another. It doesn't ever create commits.)

Note the output while doing the merge - it is saying Fast Forward.

In such situations, you want to do:

git merge <name-of-branch> --no-commit --no-ff

Important: If you do it this way, then you are not able to do any changes to the files in the staging area e.g. you can't remove/add files or make any changes to the files.

If you want to merge the changes and then commit as if you had manually typed all of the changes you merged in (as opposed to a traditional merge) you need to run rm .git/MERGE_HEAD afterward, which will force git to forget that the merge happened.

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

You want commit-squashing, which can be done in several ways:

• If you want fine-grained control over which commits are contained in the squash, if you want to squash your feature commits into more than one commit (e.g. to split up logical changes), or if you only want to change the commit messages, "rebasing interactively" (git rebase -i) is for you.
• If you want to do it quick and merge all of the concerned commits into one, you can use the --squash option to git merge, git rebase and git pull

More about both topics can be found in Chapter 6 of the Pro Git book and in the man pages of the commands, linked above.

If you inspected contents of .git directory after doing git merge --squash you would see SQUASH_MSG file that contains a commit message template. This file is also created after doing a squash with git rebase -i. You need to remove this file if you don't want Git to populate commit message automatically when doing git commit. If would be useful to alias a native git commit command to do this automatically for you but it's not possible with Git. Instead, we should create an alias like this in ~/.gitconfig:

[alias]
         kommit = "!KOMIT_GIT_DIR=$(git rev-parse --git-dir); if [ -a "${KOMIT_GIT_DIR}/SQUASH_MSG" ] ; then rm "${KOMIT_GIT_DIR}/SQUASH_MSG" ; fi && git commit"

This line checks whether SQUASH_MSG exists and removes if it does before doing git commit. Now you should do git komit instead of git commit after performing git merge --squash.

I tested this with Git 2.3.1:

$ git --version
git version 2.3.1

The flag to pass to git merge to have it not commit is called --no-commit (ref). It will do the merge, but stop just short of committing, which you can then do yourself.

git merge --no-commit branch

To always have git commit sign your commits, set commit.gpgsign to true (ref).

git config commit.gpgsign true

A good place for these kinds of questions is the reference documentation:

• git merge
• git commit

# A-B-C <-dev
#    \
#     D-E-F <-feature

git checkout feature
git rebase dev
# A-B-C <-dev
#      \
#       D-E-F <-feature

git checkout dev
git merge feature
# A-B-C-D-E-F <-dev,feature

This rebases feature onto dev and then merges it in using "fast-forward" merge, which doesn't require a merge commit. Fast-forward merges are the default in git, but you can give git merge options to make sure it only does fast-forward merges if that's what you want. I'm aware of projects that use merge commits regularly but every team I've worked on has preferred keeping a linear history.