3条Git规则，让你周五5点准时下班

周五下午5点，你终于改完了最后一个bug，心满意足地敲下 git push，脑子里已经在想晚上吃什么。

然后终端弹出一行红字：merge conflict。

你拉了一下最新代码，发现main分支的CI全红——某个同事两小时前推了一个”小改动”，直接把构建搞崩了。你不得不放下背包，坐回工位，花了两个小时帮他排查冲突。等你走出公司大门，外面已经天黑了。

这种事你经历过几次？我猜不止一次。

你以为是技术问题，其实是规矩问题

很多人觉得Git用不好，是因为命令没背熟。rebase和merge搞不清，cherry-pick不会用，stash老忘记pop。

但你仔细想想——那些让你加班到天黑的Git事故，有几次是因为你不会敲命令？

几乎没有。

真正搞崩项目的，从来不是某个人不会用 git rebase -i，而是整个团队没有约定清楚三件事：什么时候能往main上推代码？推之前要不要有人看一眼？出了问题怎么30秒内回滚？

换句话说，99%的Git灾难根本不是技术问题，而是流程问题。你们团队不是缺一个Git高手，而是缺三条写在墙上的规矩。

一个反直觉的事实

Google有超过10万名工程师，他们的代码全放在一个巨大的monorepo里，所有人基本都往主干提交。Meta也差不多，工程师直接在主分支上开发，每天部署几百次。

而我见过很多5到10人的小团队，用的是完整版的Git Flow——develop分支、release分支、hotfix分支一个不少，光分支命名规范就写了两页A4纸。

结果呢？Google每天部署上百次，很少出事。那个10人小团队每周部署一次，每次部署都像在拆炸弹。

复杂的流程并不能带来稳定性，能带来稳定性的是适合你团队规模的简单规则。

为什么会这样？因为规则越复杂，犯错的机会就越多。Git Flow有5种分支类型，每种有不同的合并方向和命名规范。一个新人加入团队，光搞清楚”我这个bug应该从哪个分支拉、最后合到哪”就需要半天。搞不清楚的时候怎么办？瞎搞呗。然后就出事了。

红绿灯理论

打个比方。一个十字路口，只需要一组红绿灯就能让车辆有序通行——红灯停，绿灯走，黄灯慢一点。三条规则，谁都看得懂。

现在想象你给这个十字路口装了6种信号灯：直行灯、左转灯、右转灯、行人灯、非机动车灯、紧急车辆优先灯。每种灯有不同的时间周期和触发条件。

理论上这套系统更精确，但实际上呢？没有人看得懂。司机到了路口一脸懵：我到底该看哪个灯？犹豫两秒钟，追尾了。

Git Flow就是那6种信号灯。它是为大型软件发布周期设计的——有明确的发布窗口、有专门的release manager、有严格的hotfix流程。如果你的团队不是在做这种量级的事情，它就是过度工程化。

你需要的不是一套完美的交通管制系统，你需要的是一个红绿灯。

好消息是，这个”红绿灯”我已经帮你造好了。

三条规则，就这么简单

我把话说得直接一点：如果你的团队有3到15个人，用以下三条规则就够了。别急着说”我们情况特殊”——先看完再说。

规则一：main分支永远可部署。

这条是地基。什么叫”永远可部署”？就是任何时候、任何人拉下main的代码，都能直接编译通过、测试通过、跑起来。

在main上直接写代码，就好比在高速公路上掉头——你觉得你技术好不会出事，但你把后面所有车都逼停了。

怎么做到？很简单：没有人被允许直接push到main。所有代码都通过Pull Request合并进来，合并之前CI必须绿。这不是多此一举，这是底线。

规则二：所有改动走短命分支，活不过两天。

从main拉一个feature分支，改完就合回去。分支名随意，feat/login-page、fix/header-bug 都行，命名不重要，短命才重要。

为什么是两天？因为一个分支存活的时间越长，和main的差异就越大，合并冲突的概率就呈指数级上升。你在分支上憋了一周的大功能，合回main的时候发现已经面目全非——这时候你是改你的还是改他的？谁都说不清。

如果你发现一个feature分支活了超过两天还合不回去，那说明这个功能拆得不够细。不是Git的问题，是任务拆分的问题。把大象装冰箱分三步，别想一步把整头象塞进去。

到这里你可能觉得：就这？这也太简单了吧。别急，最后一条才是灵魂。

规则三：合并前必须过CI + 至少一个人review。

CI是机器帮你看代码有没有基本的语法错误、测试有没有挂。Review是让一个人帮你看有没有逻辑漏洞。

很多人抗拒code review，觉得是在找茬、浪费时间。但换个角度想——review不是为了证明你写得烂，而是为了万一出事的时候有人跟你一起扛。

你一个人偷偷推上去的代码，出了事就是你一个人的锅。经过review的代码出了事，那是两个人一起判断失误，责任分摊，心态完全不一样。

而且说实话，review的过程本身就是知识传播。你的队友看了你的代码，下次遇到类似的模块他就能上手。不做review的团队，每个人都在自己的信息孤岛上写代码——某天有人请假或者离职，剩下的人看着那坨代码像看天书。

“但我们团队情况特殊啊”

每次我推荐这三条规则，必定有人举手。我来替你们问了：

“我们有专门的测试环境，需要release分支啊。”

你试过用tag吗？git tag v2.3.1 打个标签，比养一个永远不死的release分支省心一百倍。长期存活的分支就像办公室冰箱里那盒不知道谁放的酸奶——每个人都看见了，没人敢动，也没人敢扔。

“我们同时要维护多个版本。”

那你确实需要更复杂的策略。但说真的，你确定你的团队是这种情况吗？大部分说”我们要维护多版本”的团队，其实只是没做好灰度发布。先把这三条跑起来，真到了需要的那天再加规则。别给自己预支焦虑。

“我们就两个人，review不是自己看自己？”

两个人更要互相review——因为你们一个人倒下了，另一个得能顶上。就算退一万步，自己给自己提PR、自己看一遍diff再合，都比直接push强。你发微信之前都会检查一遍有没有发错人，代码难道不值得同样的待遇？

回到那个周五的下午

如果你的团队用了这三条规则，那个周五下午会发生什么？

你的同事改完代码，提交了一个PR。CI跑了一遍，发现构建挂了——他的”小改动”其实漏了一个import。CI红了，PR合不进main。他自己修好了再提交，另一个同事帮他review了一下，没问题，合进去了。

你5点钟 git pull 拿到最新代码，一切正常。你关掉电脑，准时下班。

好的Git工作流不是让你变成Git命令行大师，而是让你周五5点准时走出公司大门。

三条规则，足矣。