What's the difference between git merge --no-ff and git merge --squash

Question

I've working with a small team using the 'merge workflow' and we recently switched over to the 'rebase workflow' as per Sandofsky's article.

our current workflow:

1. git checkout master, git pull origin master
2. git checkout -b feature_branch, do some work and git commit -am "msg for feature branch"
3. git checkout master, git pull origin master, git rebase master feature_branch
4. git checkout master, git merge --squash
5. git commit -am "msg for master branch", git push origin master

After rebasing the feature branch, we squash merge it into our master. What would happen if we used --no-ff instead? What is the difference between git merge --squash and git merge --no-ff?

Answer 1

--squash creates a single commit with all the merge's changes (it squashes the entire merged branch's history into one commit). --no-ff also merges in a branch, creating a merge commit and retaining the entire history of the merged branch.

Answer 2

git merge --squash creates a single commit that applies all the changes you would apply with a normal merge. So, it melds all the commits you would bring to the branch in a single commit.

git merge --no-ff prevents fast-forwards - the operation of just moving the branch pointer to a newer commit if the source and target haven't diverged. So, using --no-ff you guarantee you'll have a new commit whose parents will be your current HEAD and the feature_branch head.

When you log both scenarios, in the first one you'll just see a single line of commits, each one being a feature_branch digest, while in the second one you'll see lots of ramifications, one for each feature_branch, and all joining master again.

As git merge --squash generates a new commit based on the feature_branch ones, they are different commits, so you can have trouble if you published feature_branch alone - say, you can git merge --squash feature_branch multiple times without git understanding it, but you'll have conflicts.