两地协作后，Git 分支改了三条规矩

两地都开始往同一个仓库提交之后，两周出了三次合并冲突。最麻烦的一次不是代码，是有人把灰度用的配置文件覆盖回了旧版，第二天测试环境跑的行为对不上，查了一上午。坐下来把规矩收了收，最后写成三条，贴在仓库 README 第一行。

1. main 不接受直接 push

以前人少，谁改完谁 push 到主干，图快。两地之后不行了，得走合并请求，哪怕只是改一行文案。要求至少一个人看过，两地各算一个人，顺便让另一边知道这边在动什么。

灰度配置那次之后，我们把配置文件单独放一个目录，加 CODEOWNERS，动它必须两边都点头。

2. 分支名带项目、日期、干的事

以前分支叫 fix、test、new，三天以后没人记得是谁的。现在格式是 项目缩写/日期/简短动作，比如 ly/20210414/recon-export。一眼能看出是哪套系统、哪天开的、要干嘛。

超过 3 天没提交的分支，CI 里加了个检查，每天扫一遍，在群里列出来。不是催，是防那种「开了一半忘了」的分支挂到年底。

3. 每天下午四点前 push 一次

这条最土，也最有用。不要求做完，哪怕写到一半、跑不通，也推上去，提交说明写「wip」。两地时差没有，但节奏会差：昌平下午在改的东西，武汉晚上接手时能看到，不用等第二天问。

配套的是提交说明不许只写一个「update」。我们没上格式校验那么严，只要求写清改了哪个文件、为什么。那次覆盖配置如果说明里写了「回退灰度开关」，一上午就省了。

顺带做的两件小事

• 把 .env.example 补全了，新同事拉下代码不用再私聊问数据库端口。
• 合并请求的模板里加了三个勾选项：本地跑过没、有没有改配置、定时任务有没有受影响。第三项是给对账那套系统专门加的，吃过亏。

一个月后

又数了一次，冲突还有，但都是真冲突，两边确实改了同一段逻辑，不是谁覆盖了谁。这种反而好办，拉个会十分钟说清。

README 那三条现在还挂着，一个字没改。