Merge commit without squash vs with squash option

Question

On daily routine i use SmartGit as client of choose. My team members however stick to git native, non commercial GUI. We discovered some differences in how our merge commits looks like.

Those are options that SmartGit gives when requested to merge branch:

On below graph you can see my example SmartGit graph output, containing:

• single master branch
• One branch merged to master with merge commit option
• One branch merged with simple commit option

One of branches (with_merge_branch) is visualizing merge operation by joining branch with master via line. Second one (normal_commit_branch) does not.

Question is, how to enforce both behaviors in native git commands? I.e. whats the difference between those two commits?

Solution 1

The difference between the two kinds of merge are only different in the commit history (as you showed the logs in graph).

Let's illustrate by graphs. Assume the commit history as below before merging:

A---B---C---D  master
     \
      E---F---G  develop

Merge commit (multiple parents):

The command used is git merge branchname. It's the default way to merge two branches.

When you merge develop branch into master branch by Merge commit in SmartGit (git merge develop), the commit history will be:

A---B---C---D---M  master
     \         /
      E---F---G    develop

Simple commit (one parent, "squash"):

It merges two branches with --squash option, the command used is git merge branchname --squash.

--squash

Produce the working tree and index state as if a real merge happened (except for the merge information), but do not actually make a commit, move the HEAD, or record $GIT_DIR/MERGE_HEAD (to cause the next git commit command to create a merge commit). This allows you to create a single commit on top of the current branch whose effect is the same as merging another branch (or more in case of an octopus).

When you merge develop branch into master branch by simple commit in SmartGit (git merge develop --squash), it get the changes from develop branch into master branch as a new ordinary commit (as if a real merge happened), and the commit history will be:

A---B---C---D---M  master
     \                 
      E---F---G    develop

Solution 2

merge commits are just commit but the difference is they have more than one parents. as you know commits may or may not have parent commit, in fact the merge commit is the commit that have more than one parent commit.

Comments

[Tim Biegeleisen]

Possible duplicate of In git, what is the difference between merge --squash and rebase?

[Tim Biegeleisen]

I've never used it, but git merge with the squash option removes any trace of there being a second parent branch. If you follow the duplicate link, you'll see some examples of why you might want to use it. Merging without the squash option is the default behavior of git merge.

[Tomas]

Just to supplement fantastic answer by @Marina, in case of some integrations (in my case it's GitLab) internal merge request system is unable to detect merged branches if once use -squash commit into parent branch. So on one side you have cleaner history but detection of merge origin is a bit harder

[cmaster - reinstate monica]

I think, a warning is in order: Squash commits lose history! If you merge, git will know all the intermediate step that lead to the feature integration, and git bisect will be able to pinpoint any regression to one of these intermediate steps. If you squash, your feature branch becomes a black box to git, and git bisect will only be able to point out the one squash commit that contains the entire feature development. Best embrace the DAG history model of git wholeheartedly, it'll save you many headaches down the road.