Git协作实战：从工作区、分支管理到 Pull Request 工作流

很多人第一次认真学 Git，都是从命令开始。结果是命令记住了一些，一到多人协作就开始发怵：为什么明明只是改了几个文件，最后却把分支搞乱了；为什么别人一句“提个 PR 吧”，自己就得先补一堆提交记录；为什么线上问题刚修完，回头再看仓库历史已经说不清这次变更到底改了什么。

问题通常不在于命令不够熟，而在于没有建立起一套工程协作的视角。Git 不是“代码备份工具”，它本质上是在帮团队记录变化、隔离风险、组织协作、回溯问题。把这个视角建立起来之后，很多原本零碎的命令才会真正连成一条线。

先分清 Git 和 GitHub

这两个词经常一起出现，但职责并不一样。

Git 负责版本控制本身，管理提交历史、分支、合并和回退。
GitHub 是远程协作平台，围绕仓库提供 Pull Request、Issue、Code Review、Release 等能力。

一句话说清楚就是：Git 解决“怎么管理版本”，GitHub 解决“怎么围绕版本做协作”。

如果你只会本地 add、commit、push，那你只是会用了 Git 的一部分；真正进入项目协作，核心其实是分支策略、提交粒度、PR 质量和问题回溯。

先把 Git 的四层结构想明白

很多人一上来就背命令，背到后面还是混乱，是因为没有把 Git 的四层流转关系想清楚。

工作区：你当前正在编辑的文件。
暂存区：这次准备提交的变更集合。
本地仓库：已经形成历史记录的提交。
远程仓库：团队共享的代码仓库。

一个最常见的工作流其实就是下面这条链路：

git status
git add <file>
git commit -m "feat: add async request queue"
git push origin feature/async-request-queue

这里最容易被忽略的一点是：git add 不是“顺手点一下”，而是在明确告诉 Git，“这一次提交我要包含哪些改动”。也正因为有暂存区，提交才能做到有边界、有语义，而不是把一整天的所有改动都糊成一个 commit。

日常开发里，一套顺手的工作流比命令大全更重要

如果是个人小仓库，很多人喜欢直接在 main 上改，短期看很省事，长期基本都会出问题。只要开始做稍微像样一点的功能，或者需要和别人协作，就应该把分支用起来。

我更推荐下面这套朴素但稳定的流程：

git switch main
git pull origin main
git switch -c feature/async-scheduler

# 开发、修改、测试

git status
git add <files>
git commit -m "feat: implement async scheduler"
git push -u origin feature/async-scheduler

这套流程背后的原则很简单：

main 保持相对稳定，不直接堆实验性修改。
新功能、新优化、新文档都在独立分支上做。
一个分支只解决一个明确问题，这样 review 和回溯都更清楚。

在 AI Infra 或推理工程里，这一点尤其重要。一次性能优化可能同时涉及 kernel、调度、benchmark 和文档，如果没有分支隔离，后面排查性能回退时会非常痛苦。

分支管理的重点，不在于花哨，而在于边界清楚

分支的价值只有两个：并行开发，和风险隔离。

一个仓库里最怕的不是分支多，而是分支命名混乱、职责不清。相比“我的分支”“新版本分支”这种模糊名字，更建议直接把意图写进名称里：

feature/...：新功能
fix/...：问题修复
perf/...：性能优化
docs/...：文档更新
refactor/...：重构整理

比如：

feature/continuous-batching
perf/triton-layernorm
fix/cuda-stream-sync
docs/deployment-guide

当分支名和提交信息都带着明确语义时，仓库历史会清爽很多。别人打开 PR，不需要先猜“你这次到底想干什么”；过几个月回头看，你自己也能快速找回上下文。

merge 和 rebase，真正的差别是“保留轨迹”还是“整理轨迹”

这是 Git 里最常见、也最容易讲虚的一组概念。简单说：

merge 是把两条历史接起来，保留真实分叉轨迹。
rebase 是把当前分支的提交重新放到另一条分支后面，让历史更线性。

它们都能把代码合起来，但适用场景不一样。

如果是团队共享分支，merge 更稳，因为它不会改写已经共享出去的历史；如果是你自己的功能分支，在提 PR 之前用 rebase 整理一下历史，通常会更干净。

一个很实用的经验是：自己的分支可以整理，共享的历史不要乱改。

很多 Git 事故，其实不是不会命令，而是对“改写历史”这件事没有敬畏。尤其是在公共分支上随手 rebase，往往比一次普通冲突更麻烦。

冲突不可怕，可怕的是没有处理原则

冲突本身并不说明你做错了什么，它只是说明两边改到了同一块地方，Git 没法替你判断该留哪份。

真正重要的是处理冲突时的顺序：

先理解双方改动各自解决了什么问题。
再决定应该保留哪部分逻辑，而不是只盯着冲突标记删哪一边。
解决后重新测试关键路径，尤其是接口、配置和文档。

在实际项目里，冲突最怕“机械解决”。把标记删掉不代表问题结束了。如果一边改了数据结构，另一边改了调用方式，看起来冲突已经消失，运行时仍然可能出错。

所以解决冲突时，视角不要停在文件层，而要回到变更意图本身。

回退操作里，最该谨慎的是 `reset --hard`

Git 提供了很多“撤销”手段，但语义并不一样。

git restore <file>：撤销工作区改动。
git restore --staged <file>：把文件从暂存区拿出来。
git revert <commit>：新建一个反向提交，适合公共历史。
git reset --soft HEAD~1：回退提交，但保留代码改动。
git reset --hard HEAD~1：回退提交，同时丢弃改动。

其中最容易出事的是 reset --hard。它不是不能用，而是要非常清楚自己在丢什么。对已经共享出去的提交，优先考虑 revert；对本地尚未共享、且确定不需要保留的改动，才谈得上 reset --hard。

一句经验足够概括：公共历史用 revert，本地实验性历史才考虑 reset。

真正能体现工程味的，不是 push，而是 Pull Request

很多人把 GitHub 只当成一个远程仓库，其实项目协作的重点恰恰在 PR 上。

一个好的 Pull Request，至少应该回答三件事：

这次改动要解决什么问题。
改了哪些核心点。
怎么验证这些改动是有效的。

一个简单但有效的 PR 描述，通常可以写成这样：

## Background
修复异步调度队列在高并发下的请求堆积问题

## Changes
- 重构请求入队逻辑
- 增加队列长度监控
- 补充 benchmark 脚本

## Validation
- 单测通过
- 本地压测吞吐提升 12%
- 文档已同步更新

这样做的好处很直接：reviewer 不需要先读完整个 diff 才知道你在做什么；后面查历史时，也能很快找回这次改动的背景、范围和验证方式。

提交信息、`.gitignore` 和文档，决定了仓库是不是“能长期维护”

写得差的仓库，问题通常不是代码完全不能跑，而是历史不可读、边界不清楚、交接成本高。

提交信息就是一个很典型的例子。update、fix bug、change code 这种信息短期省事，长期几乎没有信息量。更好的写法，是把“动作”和“对象”都写清楚：

feat: add async request batching
fix: handle empty input in decode path
docs: update local deployment guide
perf: reduce host-device sync in benchmark

.gitignore 也是一样。它看起来不起眼，但能直接决定仓库里会不会混进缓存、日志、构建产物、临时配置和大文件。一个干净的仓库，往往从忽略规则就能看出维护者是否有基本工程习惯。

文档则是另一个经常被低估的点。代码可以解释“系统怎么实现”，文档负责解释“别人怎么接手”。当你愿意同步更新 README、部署步骤、验证方法和已知限制时，这个仓库才真正开始像一个项目，而不是一段孤立代码。

最容易踩的几个坑

最后收一下最常见的几个问题：

直接在 main 上长期开发，导致主线越来越脏。
一个 commit 塞进太多无关改动，后面很难 review 和回退。
改了行为却不改文档，别人只能靠猜。
在公共分支上随意 rebase，把共享历史改乱。
不理解 reset --hard 的语义就直接执行。

这些问题单看都不复杂，但它们会持续吞掉团队时间。Git 真正的价值，不是在顺利的时候让你多快，而是在混乱快出现时，帮你把代价降下来。

写在最后

如果要我用一句话概括 Git 的学习重点，那就是：不要把它学成命令表，而要学成协作系统。

你当然需要会 add、commit、push、pull、merge、rebase，但更重要的是知道什么时候该开分支，什么时候该提 PR，什么时候该保留历史，什么时候该回退，什么时候该先补文档再合并代码。