Just to build on knittl's existing answer, here's a scenario you can enact in the comfort of your own home to demonstrate how easily a so-called "squash merge" can result in a conflict.
We start by making file on master and committing it:
$ git init
$ echo "a" >> a.txt
$ git add .
$ git commit -m'start'
Now we create develop and modify that file:
$ git branch develop
$ git checkout develop
$ echo "b" > a.txt
$ git add .
$ git commit -m'changed a to b'
We return to master and do a "squash merge", and it appears to work fine:
$ git checkout master
$ git merge --squash develop
$ git commit -m'a squash commit from develop'
So far so good. Now we make a terrible mistake: we do it again. We switch to develop and modify that file some more:
$ git checkout develop
$ echo "c" > a.txt
$ git add .
$ git commit -m'changed b to c'
And we return to master and do a "squash merge" again:
$ git checkout master
$ git merge --squash develop
Aaaaaand we get a conflict. Game over.
What happened? Well, the problem is that a "squash merge" is not a merge. It's a sort of self-inflicted patch. It constructs a configuration of the index (staging area), and you commit it. In my enactment above, we committed it as a separate step; with GitHub, it is committed for you. But the point is that that commit, although it contains the changes that would accrue from a real merge, is not a merge commit: it is just a normal commit, as if you had done those changes yourself, working directly on master.
Well, what does it mean to make the changes that would accrue from a real merge? To answer that, you have to know how a merge works:
A merge starts by calculating the common point from which the merging branches diverged: the merge base.
It then calculates two diffs: From the merge base to the end of the first branch, and from the merge base to the end of the second branch.
Finally, it enacts both diffs on the merge base.
Okay, so try that yourself, using a thought experiment.
For the first "squash merge" in my scenario above, the merge base is "start", where a.txt is "a". So:
On master, it is still "a", so there is no diff to enact.
On develop, it is "b", so the diff is change-"a"-to-"b".
So, to form the "squash merge" commit, we just change "a" to "b".
Very well, let's proceed to the second "squash merge" in my scenario. Here's the thing: the merge base is still "start", where a.txt is still "a". So:
On master, the diff is change-"a"-to-"b".
(Note that master doesn't "know" that this happened because of any kind of merge; it thinks that this change was performed independently by someone working directly on master.)
On develop, the diff is change-"a"-to-"c".
But you can't do both; that's a conflict!
So you see, the reason why reusing a branch that was previously squash-merged is troublesome is that the merge base does not move (and nothing in the history involves any merging); and so every successive squash merge is a potential conflict with an earlier "squash merge" of the same branch.
