理解Git的工作流程
理解 Git 的工作流程
英文原文：Understanding the Git Workflow By Benjamin Sandofsky
如果你不理解 Git 的设计动机，那你就会处处碰壁。知道足够多的命令和参数后，你就会强行让 Git 按你想的来工作，而不是按 Git 自己的方式来。这就像把螺丝刀当锤子用，也能把活干完，但肯定干的差极了，花费很长时间，还会弄坏螺丝刀。
想想常见的 Git 工作流程是怎么失效的吧。
- 从 master 分支创建一个新分支
- 在该分支进行工作
- 完成工作后将其合并回 master 分支
多数时候这样做的效果会如你所愿，因为从你创建分支到合并回去之间，master 一般都会有些变动。然后，有一天当你想把一个功能（feature）分支合并进 Master 的时候，而 Master 并没有像以往那样有变动，问题来了：这时 Git 不会进行合并 commit，而是将 Master 指向功能分支上的最新 commit。称为 fast-forward
不幸的是，你的功能分支有用来备份代码的 commit（作者称之为checkpoint commit），这些经常进行的 commit 对应的代码可能处于不稳定状态！而这些 commit 现在没法和 Master 上那些稳定的 commit 区分开来了。当你想回滚的时候，很容易发生灾难性后果。
于是你就记住了：“当合并功能分支的时候，加上 -no-ff 选项强制进行一次全新的 commit。”嗯，这么做好像解决问题了，那么继续。
然后一天你在线上环境中发现了一个严重 bug，这时你需要追溯下这个 bug 是什么时候引入的。你运行了 bisect 命令，但却总是追溯到一些不稳定的 commit。因此你不得不放弃，改用人肉检查。
最后你将 bug 范围缩小到一个文件。你运行 blame 命令查看这个文件在过去 48 小时里的变动。然后 blame 告诉你这个文件已经好几周没有被修改过了 —— 你知道根本不可能没有变动。哦，原来是因为 blame 计算变动是从第一次 commit 算起，而不是 merge 的时候。你在几周前的一次 commit 中改动了这个文件，但这个变动今天才被 merge 回来。
用 no-ff 来救急，bisect 又临时失效，blame 的运作机制又那么模糊，所有这些现象都说明一件事儿，那就是你正在把螺丝刀当锤子用。
1. 反思版本控制
版本控制的存在是因为两个原因。
首先，版本控制是用来辅助写代码的。因为你要和同事同步代码，并经常备份自己的代码。当然了，把文件压缩后发邮件也行，不过工程大了大概就不好办了。
其次，就是辅助配置管理工作。其中就包括并行开发的管理，比如一边给线上版本修复 bug，一边开发下一个版本。配置管理也可以帮助弄清楚变动发生的具体时间，在追溯 bug 中是一个很好的工具。
一般说来，这两个原因是冲突的。
在开发一个功能的时候，你应该经常做备份性的 commit。然而，这些 commit 经常会让软件没法编译。
理想情况是，你的版本更新历史中的每一次变化都是明确且稳定的，不会有备份性 commit 带来的噪声，也不会有超过一万行代码变动的超大 commit。一个清晰的版本历史让回滚和选择性 merge 都变得相当容易，而且也方便以后的检查和分析。然而，要维护这样一个干净的历史版本库，也许意味着总是要等到代码完善之后才能提交变动。
那么，经常性的 commit 和干净的历史，你选择哪一个？
如果你是在刚起步的创业公司中，干净的历史没有太大帮助。你可以放心地把所有东西都往 Master 中提交，感觉不错的时候随时发布。
如果团队规模变大或是用户规模扩大了，你就需要些工具和技巧来做约束，包括自动化测试，代码检查，以及干净的版本历史。
功能分支貌似是一个不错的折中选择，能够解决基本的并行开发问题。当你写代码的时候，可以不用怎么在意集成的问题，但它总有烦到你的时候。
当你的项目规模足够大的时候，简单的 branch/commit/merge 工作流程就出问题了。缝缝补补已经不行了。这时你需要一个干净的版本历史库。
Git 之所以是革命性的，就是因为它能同时给你这两方面的好处。你可以在原型开发过程中经常备份变动，而搞定后只需要交付一个干净的版本历史。
2. 工作流程
考虑两种分支：公共的和私有的。
公共分支是项目的权威性历史库。在公共分支中，每一个 commit 都应该确保简洁、原子性，并且有完善的提交信息。此分支应该尽可能线性，且不能更改。公共分支包括 Master 和发行版的分支。
私有分支是供你自己使用的，就像解决问题时的草稿纸。
安全起见，把私有分支只保存在本地。如果你确实需要 push 到服务器的话（比如要同步你在家和办公室的电脑），最好告诉同事这是私有的，不要基于这个分支展开工作。
绝不要直接用 merge 命令把私有分支合并到公共分支中。要先用 reset、rebase、squash merges、commit amending 等工具把你的分支清理一下。
把你自己看做一个作者，每一次的 commit 视为书中的一章。作者不会出版最初的草稿，就像 Michael Crichton 说的，“伟大的书都不是写出来——而是改出来的”（“Great books aren’t written – they’re rewritten.”）。
如果你没接触过 Git，那么修改历史对你来说好像是种禁忌。你习惯于认为提交过的所有东西都应该像刻在石头上一样不能抹去。但如果按这种逻辑，我们在文本处理软件器中也不应该使用“撤销”功能了。
实用主义者们直到变化变为噪音的时候才关注变化。对于配置管理来说，我们关注宏观的变化。日常 commit（checkpoint commits）只是备份于云端的用于“撤销”的缓冲。
如果你保持公共历史版本库的简洁，那么所谓的 fast-forward merge 就不仅安全而且可取了，它能保证版本变更历史的线性和易于追溯。
关于 -no-ff 仅剩的争论就只剩“文档证明”了。人们可能会先 merge 再 commit，以此代表最新的线上部署版本。不过，这是反模式的。用 tag 吧。
3. 规则和例子
根据改变的多少、持续工作时间的长短，以及分支分叉了多远，我使用三种基本的方法。
1）短期工作
绝大多数时间，我做清理时只用 squash merge 命令。
假设我创建了一个功能分支，并且在接下来一个小时里进行了一系列的 checkpoint commit。
git checkout -b private_feature_branch
touch file1.txt
git add file1.txt
git commit -am "WIP"完成开发后，我不是直接执行 git merge 命令，而是这样：
git checkout master
git merge --squash private_feature_branch #并不会像普通git merge xx一样自动提交，需要后面手动提交
git commit -v #打开新的编辑器编辑这一次提交记录然后我会花一分钟时间写个详细的 commit 日志。
2）较大的工作
有时候一个功能可以延续好几天，伴有大量的小的 commit。
我认为这些改变应该被分解为一些更小粒度的变更，所以 squash 作为工具来说就有点儿太糙了。（根据经验我一般会问，“这样能让阅读代码更容易吗？”）
如果我的 checkpoint commits 之后有合理的更新，我可以使用 rebase 的交互模式。
交互模式很强大。你可以用它来编辑、分解、重新排序、合并以前的 commit。
在我的功能分支上：
git rebase --interactive master 或者 git rebase -i master
然后会打开一个编辑器，里边是 commit 列表。每一行上依次是：要执行的操作、commit 的 SHA1 值、当前 commit 的注释。并且提供了包含所有可用命令列表的图例。
默认情况下，每个 commit 的操作都是“pick”，即不会修改 commit。
pick ccd6e62 Work on back button
pick 1c83feb Bug fixes
pick f9d0c33 Start work on toolbar我把第二行修改为“squash”，这样第二个 commit 就会合并到第一个上去。
pick ccd6e62 Work on back button
squash 1c83feb Bug fixes
pick f9d0c33 Start work on toolbar保存并退出，会弹出一个新的编辑器窗口，让我为本次合并 commit 做注释。就这样。
4. 舍弃分支
也许我的功能分支已经存在了很久很久，我不得不将好几个分支合并进这个功能分支中，以便当我写代码时这个分支是足够新的的。版本历史让人费解。最简单的办法是创建一个新的分支。
git checkout master
git checkout -b cleaned_up_branch
git merge --squash private_feature_branch
git reset现在，我就有了一个包含我所有修改且不含之前分支历史的工作目录。这样我就可以手动添加和 commit 我的变更了。
5. 总结
如果你在与 Git 的默认设置背道而驰，先问问为什么。
将公共分支历史看做不可变的、原子性的、容易追溯的。将私有分支历史看做一次性的、可编辑的。
推荐的工作流程是：
- 基于公共分支创建一个私有分支。
- 经常向这个私有分支 commit 代码。
- 一旦你的代码完善了，就清理掉私有分支的历史。
- 将干净的私有分支 merge 到公共分支中。
私有分支
使用 tag 而不是 --no-ff：例如某个私有的特性分支 feature/feat1工作完毕后，需要将 feat1 合并到 dev的场景
- 合并
git checkout dev
git merge feat1 # 默认 --ff 形成线性记录- 打 Tag 标记合并
git tag -a "merge-feat1-$(date +%Y%m%d)" -m "Merged feat1 into main"- 推送 Tag 到远程
git push origin --tags- 查看合并记录
git log --oneline --graph --decorate --all