From reading the book Git in Practice the author mentioned two git workflows, which boil down to Merge v.s. Rebase.
Rebasing is rewriting git history. If we already pushed to remote before rebasing, we have to force push to overwrite the remote history. When we force push, two bad things could happen. First, if the remote branch is a collaborative branch to which other people can push, we are at risk of overwriting other people's commits if our local branch doesn't contain those commits. Another risk is that we could accidentally force push to the wrong remote branch (maybe because of auto-complete). This could be more severe since our local history could be far behind the remote of that branch.
If we use merge instead, we also encounter one problem. After we finish our work on our branch, we have to do two things. First, we have to make sure our branch contains all the commits on the branch we want to merge to (say, Master), some of which could conflict our changes. Instead of rebasing Master, we merge Master into our branch and resolve those conflicts. This creates a conflict resolve commit. Second, we've created a pull request on GitHub and kind people have commented, we fix those comments. Without rebasing, we have to commit again and create a comment fixing commit on remote. Now our branch is ready to be merged into Master. But if we just merge, Master will have two commits that are irrelevant if we consider commit messages as change log.
Git itself provides us a solution to this problem. "git merge --squash". Let's say we are at the point where we have resolved the conflicts and fixed the PR comments with two corresponding commits on our branch (both local and remote), now we can checkout master, and do this:
"git merge ourBranch --squash"
This command will leave our branch's history alone and squash all of our branch's commits into one modification to Master. It also generates a commit message that contains all the commit messages of our branch and we can modify it to be more precise.
After merge squash, we can push the Master branch's merge commit to remote and there's no push force involved in the whole process. No history rewriting at all. Master's history contains only clean/meaningful commits that are relevant from the change log point of view.
However, if you like to merge pull request from GitHub's website, you are out of luck. The merge button of GitHub pull request only support "git merge --no-ff" Actually even if you rebase to make sure your branch's history is nice and clean, merging from GitHub's PR will still generate a merge commit on Master that is not very informative since it's a non fast forward merge. Purists will git merge locally and push to remote Master. Why not save us some Ctrl+Tabs and give us the option for PR merging GitHub?
