(Note: I got here by following the link from a more recent question of yours. I'm not sure how much you still care about this, but might as well answer it.)
You can't make Git do a squash "merge" by default for all branches, but you can make it do a squash "merge" by default for some branches. Since you are particularly interested in making this happen only for master, that may be just what you want.
Let's do a quick1 review of what git merge really does since, in the usual Git fashion, Git complicates everything. And, this:
We use separate branches for non-trivial bug fixes and features. The branches are kept in-sync with master by performing frequent git checkout <x>; git merge master.
is reversed from what many people believe to be the "correct" work-flow in Git. I have some doubts as to whether any Git work-flow can be called "correct" :-) , but some are more successful than others, and this is definitely the reverse of one of the more successful ones. (I do think it can work well, as noted in the extended discussion below.)
1Well, I tried to keep it short. :-) Feel free to skim, although there's a bunch of important material here. If TL;DR, just jump straight to the end.
The commit graph
As you know, but others may not, in Git, much is controlled by the commit graph. Every1 commit has some parent commit, or in the case of a merge commit, two or more parents. To make a new commit, we get on some branch:
$ git checkout funkybranch
and do some work in the work-tree, git add some files, and finally git commit the result to branch funkybranch:
... work work work ...
$ git commit -m 'do a thing'
The current commit is the (one, single) commit to which the name funkybranch points. Git finds this by reading HEAD: HEAD normally contains the name of the branch, and the branch contains the raw SHA-1 hash ID of the commit.
To make the new commit, Git reads the ID of the current commit from the branch we're on, saves the index/staging-area into the repository,2 writes the new commit with the current commit's ID as the new commit's parent, and—last—writes the new commit's ID to the branch information file.
This is how a branch grows: from one commit, we make a new one, and then move the branch name to point to the new commit. When we do this as a linear chain, we get a nice linear history:
... <- C <- D <- E <-- funkybranch
Commit E (which might actually be e35d9f... or whatever) is the current commit. It points back to D because D was the current commit when we made E; D points back to C because C was current at that point; and so on.
When we make new branches with, e.g., git checkout -b, all we are doing is telling Git to make a new name, pointing to some existing commit. Usually this is just the current commit. So if we are on funkybranch and funkybranch points to commit E and we run:
git checkout newbranch
then we get this:
... <- C <- D <- E <-- funkybranch, newbranch
That is, both names point to commit E. Git knows that we're on newbranch now because HEAD says newbranch. I like to include that in this kind of drawing too:
... <- C <- D <- E <-- funkybranch, HEAD -> newbranch
I also like to draw my graphs in a bit more compact fashion. We know that commits always point "backwards in time" to their parents, because it's impossible to make new commit E before we've made commit D. So these arrows always point leftward and we can just draw one or two dashes:
...--C--D--E <-- funkybranch, HEAD -> newbranch
(and then if we don't need to know which commit is which, we can just draw a round o node for each one, but for now I will stick to single uppercase letters here).
If we make a new commit now—commit F—it causes newbranch to advance (because, as we can see from HEAD, we're on newbranch). So let's draw that:
...--C--D--E <-- funkybranch
F <-- HEAD -> newbranch
Now let's git checkout funkybranch again, and do some work there and commit it, making new commit G:
...--C--D--E--G <-- HEAD -> funkybranch
F <-- newbranch
(and HEAD is now pointing to funkybranch). Now we have something we can merge.
1Well, every commit except for root commits. In most Git repositories there is just one root commit, which is the very first commit. Obviously it cannot have a parent commit, since the parent of each new commit is whatever commit was current when we made the new commit. With no commits at all, there is no current commit yet when we make the first commit. So it becomes a root commit, and then all later commits are its children, grandchildren, great-grand-children, and so on.
2Most of the "save" work actually happens at each git add. The index/staging-area contains hash IDs, rather than actual file contents: the file contents were saved away when you ran git add. This is because Git's graph is not just of commit objects, but of every object in the repository. This is part of what makes Git so fast as compared to, e.g., Mercurial (which saves the files away at commit time rather than add time). Fortunately this, unlike the commit graph itself, is something users need not know or care about.
Git merge
As before, we have to be on some branch.1 We're on funkybranch, so we are all good to go:
$ git merge newbranch
At this point, most people seem to think that Magic Happens. It's not magic at all though. Git now finds the merge base between our current commit and the one we named, and then runs two git diff commands.
The merge base is simply2 the first commit "in common" on the two branches—the first commit that is on both branches. We are on funkybranch, which points to G. We gave Git the branch name newbranch, which points to commit F. So we're merging commits G and F, and Git follows both of their parent pointers until it reaches a commit node that is on both branches. In this case, that's commit E: commit E is the merge base.
Now Git runs those two git diff commands. One compares the merge base against the current commit: git diff <id-of-E> <id-of-G>. The second diff compares the merge base against the other commit: git diff <id-of-E> <id-of-F>.
Finally, Git attempts to combine the two sets of changes, writing the result to our current work-tree. If the changes seem independent, Git takes both of them. If they seem to collide, Git stops with a "merge conflict" and makes us clean it up. If they seem to be the same changes, Git takes just one copy of the changes.
All of this "seems" stuff is done on a purely textual basis. Git has no understanding of code. It just sees things like "delete a line reading ++x;" and "add a line reading y *= 2;. Those look different, so as long as they seem to be in different areas, it does the one delete and the one add, to the files in the merge-base, putting the result in the work-tree.
Last, assuming all goes well and the merge does not stop with a conflict, Git makes a new commit. The new commit is a merge commit, which means it has two3 parents. The first parent—the order matters—is the current commit, just as with regular, non-merge commits. The second parent is the other commit. Once the commit is safely written to the repository, Git writes the new commit's ID into the branch name, as usual. So, assuming the merge works, we get this:
...--C--D--E--G--H <-- HEAD -> funkybranch
/
F <-- newbranch
Note that newbranch has not moved: it still points to commit F. HEAD has not changed either: it still contains the name funkybranch. Only funkybranch has changed: it now points to the new merge commit H, and H points back to G, and also to F.
1Git is a bit schizoid about this. If we git checkout a raw SHA-1, or anything else that is not a branch name, it goes into a state it calls "detached HEAD". Internally, this works by shoving the SHA-1 hash directly into the HEAD file, so that HEAD gives the commit ID, rather than the name of the branch. But the way Git does everything else makes it work as though we're on a special branch whose name is just the empty string. It's the (single) anonymous branch—or, equivalently, it's the branch named HEAD. So in one sense, we're always on a branch: even if Git says that we're not on any branch, Git also says that we're on the special anonymous branch.
This causes a lot of confusion, and it might be more sensible if it weren't allowed, but Git uses it internally during git rebase, so it's actually pretty important. If the rebase goes wrong, this detail leaks out, and you wind up having to know what "detached HEAD" means, and is.
2I am deliberately ignoring a hard case here, which occurs when there are multiple possible merge base commits. Mercurial and Git use different solutions here: Mercurial picks one at (what seems to be) random, while Git gives you options. These cases are rare though, and ideally, even when they do occur, Mercurial's simpler method works anyway.
3Two or more, really: Git supports the concept of an octopus merge. But there's no need to go there. :-)
Merge changes the graph from a tree to a DAG
Merges—true merges: commits with two or more parents—have a bunch of important—critical, even—side effects. The main one is that the presence of a merge causes the commit graph data structure to change from a tree, where branches simply fork off and grow on their own, into a DAG: a Directed Acyclic Graph.
When Git walks the graph, as it does for so many operations, it usually follows all paths back. Since a merge has two parents, git log, which walks the graph, shows both parent commits. Hence this is considered a Feature:
For example, rather than a single "Merge into Master" or "Merge Master into ", git will add all the commit messages.
Git is following, and hence logging, both the original commit sequence—commits
