> 在 master 上工作的， 每个人改完直接 push 上 master.
先不论这个工作流程需要改善的地方（利用分支，或者采用 pull request 等等），
并不是 git log 是线性的就是好的，这个是 case by case 的。
原则：
需要追踪或者保持历史上下文（ historical context ）的场合下，用 git merge,
反之，**可以**使用 git rebase 来清理 log 来保持线性整洁。
⚠：此处用“可以”而不是“必须”是因为使用 git rebase 有一个黄金原则：
由于 git rebase 改变了 branch 的 history ，永远不要在别的开发伙伴可以 fetch 或准备 fetch 的 branch 上作 rebase.
具体能使用 rebase 的场景有：
1.没 push 之前，你可以在你的 feature branch 上针对 master 作 rebase 以获取别人在 master 上的修改并保持你的历史整洁。
2.pull request 被 review 过后，决定要 merge 到 master 之前，可以通过 rebase 整理历史。（因为这个分支一旦被合并将会被删掉，不存在别的开发者再 fetch 它的情况）
参考：
http://stackoverflow.com/questions/804115/when-do-you-use-git-rebase-instead-of-git-merge https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/PS: 关于 rebase 的原理
http://git-scm.com/docs/git-rebase 已经讲的很清楚了，花点时间去看看，理解概念胜过硬记流程，磨刀不误砍柴功，不是么？