24

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: SmartGit commits type

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.

git tree

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

Improve this question
2
  • Possible duplicate of In git, what is the difference between merge --squash and rebase? Commented Nov 3, 2017 at 6:47
  • 2
    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. Commented Nov 3, 2017 at 6:48

2 Answers 2

Reset to default
37

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
Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

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
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.
1

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.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.