下面是一张我正在团队项目中推进的 Git 工作流程图：
让原本凌乱的 Git 记录变得干净整洁，主要用到3种命令：
- squash
- rebase
- merge
Squash
squash 命令的主要作用是：把多个 commit 合成一个 commit。
在一个多天的开发任务里，肯定会通过随时 commit 来减少代码丢失的风险，或者临时提交代码用于发布测试，或者只是想写一点测试代码方便回滚。
这种情况下一个 feature 会对应多个 commit，而最常见的就是这些 commit message 会比较随意：
5 - 优化逻辑
4 - 发布
3 - 需求变更
2 - 修复样式
1 - 修复
0 - 完成 xx 特性
也会遇到，在某一个 commit 中添加了一些代码，在另一个 commit 中又移除了一部分。在定位问题时变得无法确定开发者的意图，要在大量的 commit 记录中不停确认差异。
所以在代码最终合入 Master 分支前，应当合并一个 feature 中的所有 commit，以此来保证 git 记录的边界清晰。
0 - 完成 xx 特性
Rebase
rebase 命令的主要作用将 commit 逐个应用到目标分支上，并按照提交顺序重新组织提交历史。 这种操作可以让代码库的提交历史更加整洁、线性，并且方便后续的代码审查和维护。
下面是一个 squash 过的 Feature 分支：
如果使用 merge 将 Master 分支合入 Feature 分支，则有可能产生新的 commit。
如果使用 rebase，则相当于把 C5 从 C2 嫁接到 C4 上。
Merge
对于 master 分支的操作，一向是越稳定的方式越好。所以依旧使用 merge 对 master 分支进行操作。
下图是我们之前已经 rebase 过的状态：
如果你的 git 工作流支持 ff 的方式合入 master，则你会得到一个干净的提交记录：
如果不支持 ff，则会多一个合并记录：
虽然不支持 ff 的工作流里会多一个合并记录，不过保持 git 记录干净的主要核心还是在于 squash 一个 feature 里的所有 commit。
--force
当在本地操作 squash 或 rebase 命令后，本地和远端的 commit 可能无法对齐：
此时 git 会提示你在 push 前先进行 pull 操作，此时我们不能进行 pull 操作，而是要使用：
$ git push --force
使用 —force 确实是一个危险的操作，所以应该避免在 master 分支上使用，这也是为什么我们依旧使用 merge 流程来操作 master 分支。
