告别代码遗失危机：掌握企业级的 Git 工作流与高级技巧

不仅是提交和拉取：重新认识 Git

几乎所有的程序员都在每天使用 Git，但令人吃惊的是，很多人对 Git 的认知依然停留在 git add、git commit 以及 git push 的老三板斧。当面对多人协作时频发的合并冲突（Conflict）、错乱的分支历史或者极其危险的代码覆盖时，由于缺乏对内核机制的理解，往往会陷入绝望的挣扎。

图 1：业界公认最为稳定成熟的 Git Flow 分支协作结构体系

你的团队还在用一条 Master 走到底吗？

在企业级开发中，规范的分支策略是保证代码交付质量的第一步。目前最主流的 Git Flow 模型，正是通过规范化的分支定义来保证代码库的安全：

• Master / Main 分支：神圣不可侵犯的只读分支，上面的每一次 Commit 必须都对应一次生产环境的发布标签（Tag）。绝对不能直接往此分支推送代码。
• Develop 分支：日常的主力开发汇聚分支。包含着下一次发布的所有最新功能，也是所有 Feature 分支的派生源点。
• Feature 分支：每个人开发各自的独立功能，命名如 feature/login-module，在开发完毕并 Code Review 后通过 Pull Request 合并回 Develop。
• Hotfix 分支：生产环境一旦发生紧急级 Bug，直接从 Master 上派生修复分支，修复后双向合并回 Master 及 Develop，防止下次发版问题重现。

拯救混乱的后悔药：Git 高级核武器

在深入理解上述规范规范流程后，遇到各种奇怪的代码丢失或历史改写，以下高级命令可以拯救你的危局：

1. 清理混乱的提交历史：Interactive Rebase

你的本地分支如果有 10 个碎片的 git commit -m "fix typo" 提交，在合并前，可以通过如下命令将它们揉合成一个华丽的修改记录：

git rebase -i HEAD~10

在这个互动界面中，把第二行到最后一行的 pick 改为 squash （或 s），你就获得了一个干净利落的代码史。

2. 揪出背锅侠的利器：Git Bisect

你知道从 v1.2.0 到现在的新版本之间有人引入了一个致命的内存泄漏，但是不知道是哪一次提交导致的？使用 Git 二分查找法：

git bisect start
git bisect bad HEAD
git bisect good v1.2.0

Git 会通过二分法迅速回滚历史版本让你测试并标定好坏，极其快速地定位到引起问题的罪魁祸首代码。

3. 终极救心丸：Git Reflog

由于误操作 git reset --hard，你的两个月辛苦写成的代码不见了？别慌，由于 Git 是一个不会真正轻易丢失数据的库（只要还没触发垃圾回收），你可以通过查看 HEAD 的移动轨迹找回任何丢失的 Commit：

git reflog
# 找到那条记录的编号，比如 HEAD@{2}
git reset --hard HEAD@{2}

图 2：优秀的辅助工具不仅能减少命令行记忆负担，甚至能帮你预见潜在的代码冲撞

结语

Git 不仅仅是一款存代码的软件，它里面蕴含的本质是分布式数据库快照理念与团队协同工程化思想。多花半个周末的时间吃透其背后的逻辑树（Tree）与有向无环图概念，你的技术成熟度以及排障能力必将迎来一次质的跃升。