下面是一张我正在团队项目中推进的 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
操作,而是要使用:
shell
$ git push --force
使用 ---force
确实是一个危险的操作,所以应该避免在 master 分支上使用,这也是为什么我们依旧使用 merge
流程来操作 master 分支。