入职第一天就把main分支搞崩了——我的Git血泪史和团队规范诞生记

badhope 2026-08-08 0 阅读17分钟

入职第一天就把main分支搞崩了——我的Git血泪史和团队规范诞生记

周一早上九点，我拎着入职材料走进新公司，工位还没坐热，导师小王就甩过来一个GitLab地址："先把代码拉下来跑一下，下午要改个bug。"

我心想这有什么难的，git clone一把梭，然后git push --force把我本地改的东西直接怼上去。十分钟后，公司群里CTO发了一个问号。

就一个问号。但那个问号，比我见过的任何代码评审意见都让人窒息。

第一天：从force push到"我错了"

事情是这样的。我clone完代码后，在main分支上直接改了点东西，git add . && git commit -m "fix bug"，然后推不上去——提示远程有更新。我当时脑子里只有一句话："push不上去就force push呗，Stack Overflow上都是这么写的。"

# 我当时执行的"恶魔指令"
git push --force origin main

# 然后小王在群里说：我刚提交的代码呢？？？

那一刻我才知道，--force不是"强制覆盖我自己的代码"，是"强制覆盖所有人的代码"。小王上午刚提交的一个接口优化，直接被我的操作冲没了。

还好Git有reflog，CTO淡定地打了一行命令把小王的提交找回来了：

# 找回被覆盖的提交
git reflog
git reset --hard <小王的commit hash>
git push --force origin main

# CTO只说了一句：以后别在main上直接操作

我当场就想找个地缝钻进去。入职第一天就把main分支搞崩，这记录怕是没人能破了。后来小王告诉我，他当时在工位上正准备去倒水，看到GitLab推送通知里我的名字出现在main分支上，水都没倒直接跑回来了。

"你知道main分支意味着什么吗？"小王坐在我旁边，语气像是在哄一个刚闯祸的小孩，"main是生产环境的代码。线上跑的就是这个分支。你force push覆盖了之后，如果有人在这个间隙里部署了，线上直接就是你的半成品代码。"

我听了后背发凉。好在部署系统有定时任务，间隔是三十分钟，而CTO在四分钟内就恢复了代码。如果再晚二十六分钟，后果不堪设想。

这件事让我第一次意识到，Git不只是一个"保存代码的工具"。在一个团队里，Git是所有人共享的代码基础设施，你的每一次push都可能影响到别人。一个人用Git和一群人用Git，完全是两个世界。

下午，小王给我讲了第一条Git规矩：永远不要在main分支上直接开发。要先拉分支，改完再合并。他画了一张图：main分支像是一条主干道，你不在主干道上施工，而是开一条便道（feature分支），干完活儿再把便道并回主干道。这样即使便道上出了问题，主干道不受影响。

# 正确的姿势
git checkout -b feature/fix-login-bug
# 改代码...
git add .
git commit -m "fix: 修复登录页面空指针异常"
git push origin feature/fix-login-bug
# 然后在GitLab上发起Merge Request

我学到了。但第二天，我又搞出了新花样。

第二天：分支名"fix-bug-final-v2-real"

第二天我学乖了，知道要拉分支。但分支命名这个事，没人教过我。我的分支名演化史是这样的：

# 我的分支命名"进化史"
git checkout -b fix-bug              # 太笼统
git checkout -b fix-bug-final        # 什么叫final？
git checkout -b fix-bug-final-v2     # 还有v2？
git checkout -b fix-bug-final-v2-real # 然后real是什么意思？？？

小王看到我的分支名，沉默了五秒，然后说："你知道我们GitLab上现在有多少个叫fix-bug开头的分支吗？十七个。其中十二个是你的。"

分支命名规范：类型/简短描述，类型包括 feature（新功能）、fix（修复）、hotfix（紧急修复）、refactor（重构）、docs（文档）。描述用英文小写，单词间用连字符。例如：feature/user-avatar-upload、fix/login-null-pointer。

我老老实实把分支删了重新建：

# 删掉本地和远程的烂分支
git branch -D fix-bug-final-v2-real
git push origin --delete fix-bug-final-v2-real

# 重新命名
git checkout -b fix/login-null-pointer

然后我遇到了更大的噩梦——merge冲突。

那天下午，我改完代码准备合并到main，Git提示有冲突。我打开冲突文件一看，满屏的<<<<<<< HEAD、=======、>>>>>>>，整个人直接懵了。

我当时的解决方案是：手动一个字符一个字符地改。打开VS Code的合并编辑器，左边是我的改动，右边是他的改动，中间是原始代码。我看着满屏的红绿标记，感觉自己不是在解决冲突，而是在做一道阅读理解题——而且还没有标准答案。

改了三个小时，改完以后还不确定对不对。我把文件保存了，运行了一下项目，居然能跑起来。我松了口气，觉得这事就算过去了。结果小王过来code review，看完我的冲突解决方案，差点又想把我开除了。

"你这个冲突解决得有问题，你把对方的代码全删了，只留了你自己的。"小王说这话的时候表情很复杂，像是看到了什么不可思议的东西。

我低头一看，还真是。冲突标记=======上面的代码（我的）全保留了，下面的代码（小王的）全删了。我根本没仔细看两边改了什么，只是机械地选择了"保留自己的"。如果小王没有review就合并了，他上午写的接口优化就又被我干掉了——差点重演早上的事故。

"解决冲突不是选边站，"小王深吸一口气，"你要理解两边都改了什么，然后合并成一个正确的版本。有时候两边都对，有时候两边都错了，你得自己判断。"

那天晚上我回家后，把Git官方文档里关于merge conflict的部分从头看了一遍。其实Git已经把冲突标记得很清楚了，<<<<<<< HEAD到=======之间是你当前的代码，=======到>>>>>>>之间是对方的代码。你需要做的是理解两边的意图，手动编辑成正确的结果。

还学到了一个技巧：如果冲突太复杂，可以用三方合并工具。Git会保留原始版本（共同祖先），你对比原始版本就能看出每个人到底改了什么，从而做出正确的合并决策。VS Code、IntelliJ都内置了可视化三方合并工具，比纯文本编辑强太多了。

第三天：发现rebase的存在

第三天，我决定好好研究一下Git。不看不知道，一看发现我之前用的只是Git的冰山一角。

# 以前我合并代码是这样的
git checkout main
git merge feature/xxx
# 如果有冲突，merge commit会变得很乱

# 后来我学会了rebase
git checkout feature/xxx
git rebase main
# 把我的分支"嫁接"到main最新提交之上
# 冲突解决后，提交历史是一条直线，干净利落

这让我开始思考一个问题：merge和rebase到底用哪个？

维度	merge	rebase
历史记录	保留完整分支历史，有merge commit	线性历史，无merge commit
冲突处理	一次性解决所有冲突	每次提交都可能需要解决冲突
å®‰å ¨æ€§	ä¸æ”¹å†™åŽ†å²ï¼Œç»å¯¹å®‰å ¨	ä¼šæ”¹å†™åŽ†å²ï¼Œå ±äº«åˆ†æ”¯æ Žç”¨
适用场景	合并功能分支到main	整理个人开发分支的提交
团队协作	适合多人协作的分支合并	适合个人分支同步最新代码

核心原则：永远不要rebase已经推到远程且别人正在使用的分支。rebase会改写提交历史，如果别人基于你的旧提交在开发，rebase之后他们的代码就对不上了。黄金法则——rebase只用于你自己的、还没被别人拉取的分支。

理解了merge和rebase之后，我的Git世界观被刷新了。原来我之前一直在用最笨的方式工作：拉分支、改代码、切回main、merge、删分支。如果main在我开发期间有更新，merge就会产生冲突，而我处理冲突的方式就是蛮力手改。

学会rebase之后，我的工作流变成了：拉分支、改代码、开发期间随时git rebase main把main的最新改动同步到我的分支上。这样我的分支始终基于最新的main代码，合并的时候几乎不会有冲突。即使有冲突，也是在rebase阶段分提交逐步解决的，比一次性面对一大坨冲突清晰得多。

还有一个让我相见恨晚的命令是git stash。以前我在feature分支上改到一半，突然需要切到main修个紧急bug，我的做法是把改动注释掉然后切分支。学了stash之后，一行命令就能把工作区的改动暂存起来，切完分支处理完事情再git stash pop恢复。这种小命令积攒多了，效率提升是实实在在的。

我开始主动去研究各种Git工作流模型。

从Git Flow到Trunk-Based：工作流选型

那几天我把主流的Git工作流都研究了一遍，发现不同的团队规模和项目类型适合不同的工作流。

Git Flow是最经典的工作流，由Vincent Driessen在2010年提出。它有五个分支类型：main（生产）、develop（开发）、feature（功能）、release（发布）、hotfix（热修复）。流程完善但复杂，适合有明确发布周期的项目（比如客户端App）。

# Git Flow的典型流程
# 1. 从develop拉feature分支
git checkout develop
git checkout -b feature/new-payment

# 2. 开发完成后合并回develop
git checkout develop
git merge --no-ff feature/new-payment

# 3. 准备发布时，从develop拉release分支
git checkout -b release/1.2.0

# 4. release测试通过后合并到main和develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"
git checkout develop
git merge --no-ff release/1.2.0

GitHub Flow更简洁，只有main和feature分支。拉分支、开发、PR、合并，完事。适合Web应用和持续部署的团队。

# GitHub Flow：简单直接
git checkout main
git pull origin main
git checkout -b feature/dark-mode
# 开发、提交
git push origin feature/dark-mode
# 发起Pull Request，Code Review通过后合并到main
# 自动触发CI/CD部署

Trunk-Based Development最激进，所有人都往main上提交，靠feature flag控制功能开关。适合工程能力强的团队，配合CI/CD实现高频部署。

工作流	分支数量	上手难度	发布速度	适用团队
Git Flow	5类分支	高	æ ¢ï¼Œæœ‰release分支	有固定发布周期的项目
GitHub Flow	2类分支	低	快，合并即部署	Web应用、SaaS产品
Trunk-Based	1个main	中	极快，持续部署	工程能力强、CI完善的大厂

我们团队二十来号人，做的Web产品，GitHub Flow最合适。简单、高效、不容易出错。

但我选择GitHub Flow还有一个原因：它和CI/CD天然契合。每次PR合并到main，自动触发部署流水线。不需要专门的release分支，不需要人工标记版本号（除非要打tag）。开发节奏快，上线频率高，反馈周期短。这对于一个正在快速迭代的产品来说，比什么都重要。

Git Flow的release分支流程虽然严谨，但对于Web产品来说太重了。你得维护develop分支，还得在发布前拉release分支做测试，测试完合并到main和develop两个分支。如果你每周发好几次版，光分支管理就占掉不少时间。而Trunk-Based虽然快，但要求团队有很强的自动化测试能力和feature flag管理能力，我们当时的工程基础设施还撑不住。

所以选型不是选"最好"的，而是选"最适合当前团队能力"的。

工作流选型建议：不要盲目追求"最佳实践"，适合团队规模和项目特点的才是最好的。小团队用GitHub Flow就够了，别上来就Git Flow搞五层分支；大厂工程能力强可以考虑Trunk-Based，但前提是CI/CD和自动化测试足够完善。

commit规范：让历史记录会说话

研究完工作流，我又发现一个问题：我们的commit message写得乱七八糟。有写"fix bug"的，有写"update"的，甚至有人直接写了一个句号。

# 以前我们的commit message
git commit -m "fix bug"
git commit -m "update"
git commit -m "..."
git commit -m "终于改完了"

# 学了Angular提交规范后的commit message
git commit -m "feat(auth): 新增微信扫码登录功能"
git commit -m "fix(payment): 修复支付金额计算精度丢失问题"
git commit -m "refactor(user): 重构用户信息查询逻辑，减少3次DB调用"
git commit -m "docs(api): 更新支付接口文档，补充错误码说明"

Angular commit规范的核心结构是<type>(<scope>): <subject>：

当时推行这个规范的时候，阻力比我想象的大。有人觉得"写个commit message还要想半天太麻烦了"，有人说"我一直都这么写也没出过问题"。但我在规范文档里放了一个真实的例子：有一次线上支付出了bug，我们需要从最近两周的提交里找出是哪次改动引入的。由于commit message全是"update"和"fix bug"，我们不得不一个一个点进去看diff，花了两个小时才定位到问题。如果commit message写的是fix(payment): 修改金额计算逻辑改用Decimal，一行git log --grep="payment"就能找到。

字段	说明	常用值
type	提交类型	feat（新功能）、fix（修复）、docs（文档）、style（格式）、refactor（重构）、test（测试）、chore（构建/å·¥å ·ï¼‰
scope	影响范围	模块名，如 auth、payment、user
subject	简短描述	ä¸è¶ è¿‡50个字符，用中文或英文均可，不加句号

commit message的价值：好的提交信息是给未来的自己和团队看的。半年后线上出了bug，你需要从历史记录里定位是哪次提交引入的，清晰的commit message能帮你省下几个小时。git log --oneline --grep="fix(payment)"一行命令就能筛出所有支付相关的修复记录。

Git Hooks：让规范自动执行

规范写好了，但靠人自觉是不行的。总有人忘记拉分支、忘记写规范的commit message。这时候Git Hooks就派上用场了。

Git Hooks是Git在特定事件发生时自动执行的脚本，存在项目的.git/hooks目录下。常用的有pre-commit（提交前检查）和commit-msg（提交信息校验）。

#!/bin/bash
# .git/hooks/commit-msg - 校验commit message格式

commit_regex='^(feat|fix|docs|style|refactor|test|chore)\(.+\): .{1,50}'
error_msg="你的commit message不符合规范！格式：type(scope): subject"

if ! grep -iqE "$commit_regex" "$1"; then
    echo "$error_msg"
    echo "示例：feat(auth): 新增微信扫码登录功能"
    exit 1
fi

但.git/hooks目录不会被Git追踪，团队协作时没法共享。所以我们用了husky这个工具，把hooks放在项目里，通过npm安装后自动生效：

# 安装husky
npm install husky --save-dev
npx husky init

# 添加pre-commit钩子（提交前跑lint）
echo "npm run lint" > .husky/pre-commit

# 添加commit-msg钩子（校验提交信息）
echo "npx --no-install commitlint --edit \$1" > .husky/commit-msg

Hooks的核心价值：把规范变成自动检查，而不是靠口头约定。代码不符合lint规则？提交被拦截。commit message不合规？提交被拦截。开发者不需要记住所有规范，Hooks会在关键时刻提醒你。这就是"防呆设计"——让正确的事情容易做，让错误的事情做不了。

CI集成：最后一道防线

Hooks能拦住本地的问题，但还不够。有些人的hooks可能没装上，有些检查需要在集成环境中跑。所以我们在GitLab CI里加了一道完整的流水线。

# .gitlab-ci.yml
stages:
  - lint
  - test
  - build
  - deploy

lint:
  stage: lint
  script:
    - npm install
    - npm run lint
    - npm run type-check
  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "main"

test:
  stage: test
  script:
    - npm run test:unit
    - npm run test:integration
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

build:
  stage: build
  script:
    - docker build -t app:$CI_COMMIT_SHORT_SHA .
  only:
    - main

deploy:
  stage: deploy
  script:
    - docker push registry.example.com/app:$CI_COMMIT_SHORT_SHA
    - kubectl set image deployment/app app=registry.example.com/app:$CI_COMMIT_SHORT_SHA
  only:
    - main
  when: manual

每次发起Merge Request，CI自动跑lint和测试。测试不通过？MR无法合并。代码覆盖率下降了？会在MR评论里提醒。这一套下来，质量基本有保障了。

CI流水线还解决了一个之前一直困扰我们的问题：环境一致性。以前经常出现"我本地能跑但CI跑不过"的情况，原因可能是Node版本不同、依赖版本不一致、环境变量缺失。CI用Docker容器跑，环境完全一致。本地跑不过CI？那就是你的本地环境有问题，不是CI的问题。这逼着大家把依赖和环境配置写进代码里，而不是靠"口头传帮带"来维护开发环境。

我们还加了一个比较实用的CI job：MR评论里自动展示当前改动会影响哪些API端点。通过静态分析路由定义文件，对比MR前后的差异，把受影响的接口列出来。这样测试同事就知道这次改动需要重点回归哪些接口，不用猜。

CI阶段	æ£€æŸ¥å† å®¹	失败后果
lint	代码风格、类型检查	MR无法合并
test	å•å ƒæµ‹è¯•ã€é›†æˆæµ‹è¯•	MR无法合并
build	Docker镜像构建	部署阶段不执行
deploy	镜像推送、K8s更新	手动触发，可回滚

一周后：团队Git规范文档

入职一周的时候，我把这几天的踩坑经历和研究心得整理成了一份团队Git规范文档。没想到CTO看完后直接说："这个不错，以后团队就按这个来。"

规范的核心内容其实就几条，我把它们写成了项目README里的Git Workflow章节，新人入职第一件事就是读这个：

除了基本流程，规范里还加了几条"血泪经验"。比如：不要在周五下午五点以后合并代码到main——如果出问题你得在周末加班修。再比如：合并MR前先把main的最新代码rebase到自己的分支上，确保没有冲突且CI全绿——不要寄希望于GitLab的在线冲突解决工具，有些冲突它处理不了。

还有一条是关于hotfix的：线上紧急bug修复直接从main拉hotfix/分支，修完后合并到main并立即部署。不走常规的MR review流程，但要求事后补一个postmortem文档，说明bug原因和修复方案。这条规范的起因是有次线上支付挂了，等MR review走完流程已经过了四十分钟，损失了不少订单。

# 1. 分支命名：type/简短描述
git checkout -b feature/user-avatar-upload
git checkout -b fix/payment-precision

# 2. commit message：type(scope): subject
git commit -m "feat(auth): 新增微信扫码登录功能"

# 3. 开发前先拉取最新代码
git checkout main
git pull origin main
git checkout -b feature/xxx

# 4. 个人分支同步main用rebase，合并到main用merge
git checkout feature/xxx
git rebase main  # 同步main最新代码

# 5. 合并前确保CI通过
# 发起MR，等CI绿灯，Code Review通过后再合并

规范不是目的，效率才是。好的Git规范不是为了限制开发者，而是让团队协作更顺畅。当所有人都遵循同一套规则时，你不需要猜测别人的分支命名、不需要在混乱的提交历史里大海捞针、不需要担心代码合并后出问题。规范降低了沟通成本，让团队把精力放在真正重要的事情上——写好代码。

入职第一周的Git血泪史，让我从"force push炸了main"的菜鸟，变成了团队Git规范的制定者。CTO后来在年会上还拿这事开了个玩笑："badhope入职第一天就把main搞崩了，但他也是唯一一个把崩溃经验变成团队规范的人。"

台下哄堂大笑。我也笑了，但笑里带着那天看到CTO发问号时的心有余悸。

---

你踩过什么Git的坑？force push、merge冲突、还是rebase翻车？评论区聊聊，说出来大家开心一下。