新人必看：团队协作中Git的工作流、命令与冲突解决全指南

新人入职第一周，leader 往群里丢了个 Git 仓库地址，说“代码拉下来，建个分支，把登录模块的接口调通”。我当时的反应是：GitHub 我之前也传过作业啊，不就是一个 git add、commit、push 三步走吗？结果真上了项目仓库，第一条 push 就被拒了——原因写着“protected branch”，整个人懵在原地。

这种场景我见得太多了。很多新人对 Git 的认知停留在“一个人写代码、把代码传到网上”的程度，但团队开发里的 Git 完全是另一套玩法：有分支权限、有合并规范、有 code review、有自动化流水线。你以为自己会 Git，其实只是会“存代码”而已。这篇文章我不打算从 git init 讲起，而是直接站在“你刚进团队、leader 丢给你一个仓库”的场景，把新人真正需要的东西一次讲透：团队用的是什么工作流、每天要敲哪些命令、遇到冲突怎么处理、以及那些文档里不会写但老手默认你该知道的事。

适合谁看？刚入职半年内的开发新人、实习生，以及那些一直是独自写代码、第一次用 Git 参与协作的朋友。有基础也行，重点看工作流规范部分，那部分才是团队协作和单人玩 Git 最大的区别。

1. 团队协作里的 Git，和你之前用的不是同一个东西

1.1 你之前学的是“存代码”，团队用的是“管协同”

大多数人对 Git 的第一印象来自 GitHub。一个人写个小项目，自己的分支自己开，提交信息随便写，push 之前连 pull 都不用。这套模式背后是你一个人承包了开发、测试、发布所有环节，Git 在这里充其量是个“网盘 + 时间机器”的组合体。

但团队协作里，同样一套 Git 命令，背后的约束条件完全不同：

• 代码不是只给你一个人看的，同事会 review 你的代码，commit 写得乱会被吐槽。
• 不是所有分支都能直接 push，主干分支往往有权限保护。
• 你不是最后一个碰代码的人，昨天还正常的代码可能今天就被别人改了。
• 你的代码会触发自动化测试、自动部署，push 上去的每一条 commit 都可能变成线上事故。

这就是很多新人最不适应的点：Git 在单人模式下是工具，在团队模式下是规则。工具只要会用就行，规则却需要先理解，再遵守，最后才能谈用得溜。

所以我建议新人入职第一天不要急着敲命令，先把团队仓库的 Wiki、Git 相关的规范文档读一遍。正规一点团队会有一份 Git 工作流说明，里面写着分支怎么命名、commit 怎么写、merge 还是 rebase。没有文档的团队也别慌，直接问带你的导师要一份提交记录，近一周的 commit、merge 历史翻一遍，基本就能摸清团队的协作习惯。

1.2 版本管理的本质：协同工作的“空间分配”问题

我用一个生活类比来讲团队 Git 的本质：一个项目仓库就像一间合租的大厨房，每道菜是新功能，锅碗瓢盆是共享代码文件。一个人做菜，东西放哪儿都行；但 5 个人同时做饭，你就要考虑：谁负责哪个灶台？你的食材放在哪一层冰箱？你炒菜的时候能不能动别人已经在锅里的菜？

Git 的分支就是给每个开发者的“灶台”。你在自己分支上随便折腾没问题，调料撒了、菜炒糊了都是你自己的事。但你做的菜最终要端上公共餐桌——合并回主干分支。这时候就要遵守公共规则：菜的摆盘要统一（代码风格）、每道菜要有标签说明（commit message 规范）、必须经过“试菜员”确认才能上桌（代码 review）。

理解了这个隐喻，你就掌握了团队 Git 的底层思维：

1. 分支隔离：每个任务、每个功能都在独立分支上开发，不污染主干的稳定性。
2. 提交即记录：commit 是给别人看的工作日志，不是给自己看的记事本。
3. 合并即发布：把分支合并到主干是一条不可逆的通道，越到后期代价越大。

所以整篇文章你看下来，核心其实就是一件事："在合理的时间，把正确的代码，通过合规的流程，合并到该去的地方"。新人最开始不需要理解 Git 的底层对象模型、不需要记住那些悬空提交的底层原理，先把“分支隔离 + 提交规范 + 合并流程”这三件事做对，就赢过了 80% 的新入职同事。

2. 团队主流的 Git 工作流，以及为什么你们团队选了其中一种

2.1 三种标配工作流对比：集中式、Git Flow、GitHub Flow

团队用什么 Git 工作流，通常和团队规模、发布节奏、业务性质强相关。我见过小型创业团队阶段性地把代码直接推到主干上的——不是人家不规范，是真没人；也见过几十人的团队用一整套完整的分支模型，版本发布还要打 tag、创建 release 分支——不是流程繁琐，是发布的系统实在太多、风险实在太高。但不管团队规模如何，市面上主流工作流绕不开下面这三种。

集中式工作流（Trunk-Based Development）：所有人都往同一个主干分支上开发，分支不常开，功能也不隐藏。小型团队、需要快速迭代的项目适合这种模式。优点是流程最简单，没有分支管理成本；缺点是主干随时可能处于“半成品”状态，质量靠 CI 和同事自觉撑着。

Git Flow 工作流：以 master 为线上版本分支，develop 为集成开发分支，功能从 develop 拉 feature 分支开发，完成后合并回 develop，发版时从 develop 拉 release 分支，线上紧急修复用 hotfix 分支。这套模型分工严密，适合需要严格版本管理、定期发版的大型项目，但分支多、操作重，新人刚接触时容易被分支关系绕晕。

GitHub Flow 工作流：只有一条常驻主干分支 main，任何新功能都从 main 拉分支，通过 Pull Request 的形式提合并，code review 通过后合并回 main。这是目前互联网团队最主流的方式，配合 CI/CD 可以做到随时随地发布。轻量、快速，对新人非常友好——因为永远是一条主干，你不需要记住复杂的上下游关系。

新人拿到仓库后，先别急着敲代码，第一时间确认团队用的是哪种流。我见过有的新人照着网上 Git Flow 教程在单主干仓库里硬建一条 develop 分支出来，结果每次同步都要合并两次，给自己和同事都添了麻烦。

2.2 分支命名规范：一看名字就知道你在做什么

团队协作的分支和私人仓库的分支差异很大。自己开发时名字随便起，test、dev、fix，一个词了事，没人管你，因为上下文只有你知道。团队协作里分支会被很多人看到、搜索、归并、清理，没有统一的命名规范，仓库过两个月就会变成一锅粥。

绝大多数团队采用的分支命名方式，是按类型和描述组合的。举几个真实的例子：

• feature/user-login-api：新增用户登录接口
• feature/pay-order-optimize：优化下单支付流程
• bugfix/fix-orderAmount-npe：修复订单金额空指针
• hotfix/urgent-login-timeout：紧急修复登录超时（从主干拉出、完成后快速合并）

用这套命名规则的原因在自己回头看的时候尤其能体会：两个月后你接到一个任务要排查“用户反馈登录偶发失败”的 bug，在分支列表里用关键词一搜login，相关分支一目了然，不用一个一个点开看提交记录才能猜出这分支是干嘛的。而且很多团队的 Git 服务端还配置了分支权限——比如普通开发者不允许直接往main分支 push，分支名包含了类型前缀，权限控制才能写进规则里自动生效。

命名还有一个建议：分支头和结相小，尽量拉完马上开发，开发完马上合掉删掉，不要让一个 feature 分支活过一个月。分支也是有保质期的，放久了和主干冲突越来越大，合并成本越来越高，最后没人敢碰它，成了仓库里的“僵尸分支”。

2.3 远程仓库的协作，不是 push 上去就完事了

如果用一句话概括新人最容易犯的错，我会说：把推送当成终点，而不是起点。

我见过太多新人兴冲冲写完代码，git push一敲，然后就在群里跟导师说“写完了”。实际上，在你 push 之后真正的工作才刚刚开始：

去远程仓库发一个 Pull Request（简称 PR，有的团队叫 Merge Request），在 PR 描述里写清改了什么、为什么改、怎么测试，选择合适的 reviewer 来检查你的代码——这一步在正规团队里，是代码合并进主干的必经门槛。

Reviewer 会看你的 diff、运行你的分支、给出修改建议。你觉得大功告成的代码，很可能要被打回来调整两三轮才能合。这个过程不是为了打击你，而是团队在拿所有人一起写的代码质量做一道共同把关。所以新人不要有“被 review 就是被否定”的心态，把 PR 看成一次请同事帮忙检查代码的机会，心态会轻松很多。

远程协作还有一个重要原则：改别人的代码之前，先 pull 最新的主干，基于新主干拉新分支，而不是在一个放了几天的旧分支上继续开发。主干的变动不会自动通知你，但你不主动同步，合并时产生的冲突会让你的开发效率断崖式下降。养成每天开始工作前先同步一次主干的好习惯，能帮你躲避至少一半的合并灾难。

3. 新人加入团队必须先掌握的 Git 命令清单

命令我按团队开发的真实使用频率来排，不是按教学大纲排。每一条都会先讲怎么用，再讲为什么在团队场景下要这么用，最后补一个我实际踩过的坑。这部分宁可写得啰嗦一点，因为很多问题当时一个点拨就能省掉一天以上的折腾。

3.1 克隆、同步、关联：进入开发状态的第一步

进入团队的第一步，用下面这两条命令把代码库拉到本地：

# 克隆团队仓库到本地，url 替换成你们仓库的真实地址 git clone https://github.com/team/project.git # 进入仓库目录后，确认当前在哪个分支 git branch -a

克隆完成之后，第一件事不是直接改代码，而是创建一个属于自己的分支：

git checkout -b feature/user-login-api

这里有个新手容易犯的错误：直接在 main 分支上改代码。你想想，你本地 main 分支开发了半天，另一同事已经合并了新功能，你想同步他的代码就得 pull 一下，结果git pull和你的本地改动撞在一块儿，轻则冲突提醒，重则把别人代码和自己半成品混在一起，理都理不清。所以记住一条铁律：主线分支永远保持干净，永远不要在 main 上开发。我见过最混乱的一次局面，某新同事在 main 分支上改了三天的代码，期间团队其他人合并了十几个功能，他 pull 的时候冲突从中到后列了几十个文件，最后我帮忙把本地改动用 stash 存起来、重置分支、再还原，折腾了整整一个下午。

进入团队每天开工，先同步最新代码：

git fetch origin # 更新远程所有分支的引用，不主动修改本地代码 git checkout main # 切回主干分支 git pull origin main # 更新本地主干到最新 git checkout feature/user-login-api # 回到自己的功能分支 git merge origin/main # 把最新主干合入当前功能分支

这套 4 连有一个很重要的隐蔽作用：让“主干更新”和“自己改代码”这两件事的生效边界彻底分清。git fetch和git pull很多人分不清。我这儿给你一个最省脑子的用法：fetch只下载信息，pull才是下载代码并合并。拿不准是不是自己的代码还没保存，就用fetch先看一下远程什么情况，确认没有风险再pull。熟练之后可以简化合并操作，用git pull --rebase教程里都讲 rebase，但团队开发里如果你的代码从来没有被推到过其他分支，--rebase是安全的；一旦你 push 过分支、有别人在基于你的分支开发，用 merge 更稳。新人不确定自己在什么阶段，就保守一点，用git merge。

3.2 提交的粒度与信息：Commit 是写给别人看的日志

很多新人提交代码普遍存在两个问题：要么憋了一整天写了几十个文件，一次性 commit；要么每改一行就 commit 一次，提交信息还全写“update”“最新修改”“111”。这两种习惯在自己开发时问题不大，但在团队协作里，Reviewer 想要做的事是搞清楚"这段改动是因为什么引入的、是否可以被单独理解"。

好的 commit 习惯是：一个功能点、一个 bug 修复、一次重构，单独占一个 commit。每个 commit 的粒度要小到你万一想回退，可以只撤销它而不影响其他内容。举个例子，你做“用户登录接口”，这个任务里面其实包含：

1. 新增用户表结构加几个索引
2. 新增登录接口业务代码
3. 修改前端的登录页面调用

严格来说这三件事应该分成三个 commit，分别写清楚：

feat(db): 增加用户表唯一索引，确保手机号唯一 feat(api): 新增登录接口，支持验证码校验 feat(web): 登录页改为调用新接口

至于 commit message 的规范格式，业界主流的团队都采用“类型 + 作用范围 + 描述”的结构。常见的类型有：

• feat：新功能
• fix：修复 bug
• docs：只改文档
• style：不影响代码逻辑的格式调整
• refactor：重构，不改功能只改结构
• test：补充测试
• chore：构建过程、辅助工具的变动

格式大致长这样：

feat(api): 新增用户注册接口，增加邮箱格式校验 fix(order): 修复订单金额小数计算丢失精度的问题 style(login): 格式化登录页面代码，无逻辑变化

这套规范很多新人第一反应是“很做作、很麻烦”，但一旦团队规模上来、代码量多起来，就明白它的意义重大了。你月底复盘自己做了多少事，不需要翻聊天记录，只需要git log --oneline过一遍，所有工作轨迹清清楚楚；查线上 bug 的时候，git bisect二分定位问题 commit，规范的 message 能帮你瞬间圈定嫌疑范围。

实际开发中我的建议是：代码逻辑还没完全调通，可以先在本地暂存区躺着，等确认能编译过、自测通过，再把相关文件一次性组织成规范的提交。不需要在开发每一行时就纠结这条信息怎么写，提交信息的作用是“事后给人看”的，调通后再补齐反而信息更准确。

3.3 推送、删除、撤销：你需要知道的安全操作姿势

几个高频操作在新人这里最容易出事：push 被拒、分支删不掉、撤销不知道用哪个命令。

推送，最稳的姿势是先确认当前分支和远程分支的关系：

git status # 确认当前所在分支和暂存的变更 git log --oneline -3 # 看看最近提交是什么 git push origin HEAD # 把当前分支推送到同名远程分支

push origin HEAD这个姿势，新手刚开始可能觉得不直观，但它是“在我自己分支上推送”这件事最安全的写法——不会因为分支名打错而把代码推到别的分支去。

删除分支，团队项目跑久了，远程积累一堆已经无用的分支，这些分支可删。但要分清删的是本地还是远程：

git branch -d feature/user-login-api # 删除本地已合并的分支 git push origin --delete feature/user-login-api # 删除远程分支

本地分支用了-d是安全模式，Git 会检查分支是否已被合并；如果还没合并，它会拒绝删除，此时如果你确定要强删，换成-D。远程分支删除不可逆，执行前先用git branch -r看看这个分支还在不在、确认是不是已经没有用了。

撤销，是新手最怕的操作，也是平时最容易出错的。直接给你一张行为对照表：

这里特别重点提醒最后一条：已经推送到远程的提交，几乎永远不要用 reset 去强制回退。因为远程代码别人也可能拉下来过，你用 reset 改写了历史，别人再拉代码的时候，仓库历史出现分叉，轻则 pull 报冲突，重则直接把同事本地已有的提交搞丢。正确方式是用revert追加一个“反向提交”，用一次新提交把旧提交的改动抵消掉——历史被完整保留，其他人同步时不会遇到冲突。

这个表你截图保存也好、收藏也好，建议贴在自己工位旁边。团队这两年下来，我处理过的所有“代码丢了”的求助现场，十有八九都是reset --hard用在了不该用的时候。

4. 实操：从拿到需求到提 PR，完整走通一条开发链路

前面光讲概念和命令了，这一章就把一个任务从开始到结束，按真实工作流一步步带你走完。我们统一用一个模拟的需求举例：“为订单模块增加导出 Excel 的功能，并导出前可选日期范围”。这是一个团队里非常典型的增量式开发任务。

4.1 拿到需求后：同步主干、拉分支、起名字

第一步，先把自己本地仓库同步到和远程一致的最新状态。这一步比很多人想象的重要，因为这是你整个开发周期的起始点，你后来的所有 diff 都是相对这个时间点的主干代码来计算的。

# 1. 切到主干分支 git checkout main # 2. 拉取最新代码，确定本地和相关 git pull origin main # 3. 基于最新主干拉出功能分支，命名按团队规范 git checkout -b feature/order-export-excel

拉分支这个动作建议带一个明确的意图——你是基于什么需求点、什么任务号、什么目的来拉这个分支的？命名好之后，项目代码的改动就相对独立地在自己的分支里进行，和主干暂时分道扬镳。

4.2 开发过程中：高频小步提交，写清每步在做什么

开发过程中，我不建议把代码攒到一次性做完再提交。而是每完成一个相对独立的节点就提交一次。比如这个导出功能，开发节奏大致是：

# 1. 新建 Excel 导出工具类，并且在导出接口中定义了响应结构 git add src/main/java/com/yourcompany/order/export/OrderExcelExporter.java git commit -m "feat(order): 新增订单导出 Excel 工具类，定义导出结构" # 2. 实现日期范围条件查询逻辑，接上参数 git add src/main/java/com/yourcompany/order/service/OrderQueryService.java git commit -m "feat(order): 导出接口支持按日期范围筛选订单" # 3. 写单元测试，验证导出内容和查询逻辑 git add src/test/java/com/yourcompany/order/OrderExportTest.java git commit -m "test(order): 增加订单导出功能单元测试"

这样三个 commit 下来，代码历史脉络非常清楚。整个功能模块相对独立，每一步都自洽，就算中间哪一步临时有变化，回退也只影响单个逻辑点，不会把整个功能推到重来。你也可以用git add .一次性提交所有文件，但那样会把无关的格式调整、临时日志输出混进代码里，Reviewer 看起来会非常难受。

关于提交频率我多说一句：有人提倡“每次编译通过就提交一次”，有人提倡“一个任务一个提交”。我的实践体会是：提交频率取决于你自己的把握能力，关键是提交里每一行代码你都能解释清楚它为什么存在。一个功能相关的几十个文件的提交，和一次一行的碎片提交，同样都是问题。

4.3 开发完成之后：自测、查看 diff、推送、发 PR

功能开发完了，自己先确认几件事再推送。这一步能帮团队省去大量无意义的 review 来回沟通。

# 1. 先查一下本地这份工作区的变更范围 git status # 2. 再确认代码 diff 是否符合预期， git diff --stat

确认改动范围没有误伤其他文件后，编译、跑相关的单测，把功能本地自测一遍。这两步没人替你，等推上去被 CI 拦截或被人 review 出来，来回成本就会高很多。

然后推送到远程，发 PR：

git push origin HEAD

推送成功后，去你们团队的 Git 平台（GitHub / GitLab / Gitee 都各有各的操作界面，原理一样）上发起一个 Pull Request。PR 的基本要求是：标题简练概括这次改了什么；描述里写清楚本次变更的背景、改动要点、测试情况、涉及到的关联需求或 issue 编号。这些看似琐碎的信息，是 reviewer 判断“这个改动靠不靠谱、要不要合”的第一依据。

PR 发出来后，还可以做几件事提升过审效率：

• 主动在 PR 描述里标注“改动最大风险点”：比如这次你改了订单金额计算逻辑，提醒 reviewer 重点关注，表示你有风险意识。
• 如果 PR 解决了某个缺陷，把这个 PR 关联到对应的任务单或缺陷单，团队可追踪性会强很多。
• 不要把多个不相关的功能塞进同一个 PR：比如顺手改了个单词拼写、顺手格式化了一个文件，reviewer 对莫名出现的改动非常敏感。与其被要求拆开，不如一开始就保持干净。

4.4 PR 合入之后：删除分支、同步主干、检查流水线

PR 被 review 通过、被合并进主干之后，开发任务并未结束，还有三四步收尾动作，新人特别容易漏：

# 1. 先更新本地的远程分支信息 git fetch origin # 2. 回到本地主干分支 git checkout main # 3. 拉取最新代码（这时代码已经包含了你的 PR） git pull origin main # 4. 删除本地已经被合并的功能分支 git branch -d feature/order-export-excel # 5. 删除远程已经合并的功能分支 git push origin --delete feature/order-export-excel

这几步的意义在于，主干是我方最稳定的基线，功能分支是一次性的，合并之后它的使命就结束了，不删的话真个仓库经年累月积累几百个僵尸分支，后人翻起来非常痛苦。

还有一点，合并主干后，盯着 CI / CD 页面看几分钟。团队一般都有自动化流水线，你刚合并的代码会不会触发构建失败、单测失败，很快就能看到结果。如果流水线红了，第一时间在 PR 或群里说一声并着手修复，而不是坐等同事来提醒你“构建挂了”。这个习惯直接影响同事对你的专业信任度。

4.5 代码 Review 的素养：不要怕被 review，要会回应 review

代码 review 是团队 Git 协作中非常特殊的一环，它和技术本身关系不大，更多是沟通和心态。新人第一次收到一堆 review 意见，第一反应基本都是心里有点不舒服：“我觉得我写得挺好的啊？”“原来这里还能这么写？”“这也要改吗？”

我给你们最大的建议是：把 review 意见当成免费的代码设计课。同事指出你代码的问题，不是在否定你的能力，而是避免这些问题进入主干去影响更多人。而你越早知道、越早改掉，你的成长曲线就越陡。我见过太多例子：一个新人入职三个月，写的代码质量突飞猛进，原因就是每次都认真抠 review 意见里隐含的设计原则，甚至主动追问 reviewer 为什么这么改。反观那些“改完即走、不关心为什么”的新人，半年后写出的代码和刚入职时没什么两样，該犯的坑一个没少。

收到 review 意见之后，常规的标准动作是：

1. 逐条查看意见，在有疑问的地方先补充问一下背景，不用急着改。
2. 修改之后，在原评论下回复“已修改”，并附上新的 commit 链接。
3. 每次修改尽量追加 commit，而不是去改写已经 push 过的历史。reviewer 看到 diff 还是可以一条一条往下看，如果改动被压到一个提交里，前后对比很吃力。

只要你能心态放平、沟通主动、修改及时，review 过程其实是一个很高效的互相学习过程。等你以后当了 reviewer，大概率也会以同样的方式帮助更年轻的人。

5. 团队开发中躲不开的合并冲突与疑难杂症

写代码就免不了有冲突，团队开发更是如此。这一章把新人必踩的冲突和处理策略讲透，附一份高频排查表。

5.1 冲突是怎么产生的，以及从源头减少冲突的手段

想象一个最简单的场景：你和同事同时修改了OrderService.java这个文件的第 38 行附近。你改的时候基于的是昨天的代码版本，同事基于的是大前天的版本，等你们俩的分支先后合并到主干，Git 面对同一处地方两个不同的改法，没法替你决定保留哪个、放弃哪个，于是抛出冲突，需要人类来裁决。

冲突产生最核心的根源只有一个：修改了同一处代码。但从团队协作角度，我们可以通过一些手法显著减少冲突概率：

• 小步高频合并：你的功能分支越晚合入主干、间隔越长，冲突概率越大。天天同步一次主干，和写了两周再合并，后者的痛苦完全不是一个量级。
• 代码模块划分清晰：不同团队负责不通的包，模块边界清晰，不太会同时碰到同一个文件。但这属于架构层面的事，新人更多是配合执行。
• 不要把格式化混进功能提交：老同事改代码的时候顺手格式化整个文件，整个文件 diff 满天飞，你和他的改动必然会“冲突”。任何无关的格式改动都应该单独成 commit，或者压根就别做。

新人阶段最能控制的其实是第一点。我自己有个习惯：每天上午开工前，先同步一次主干到自己的功能分支；下午下班前，再看一眼主干有没有新变化。看起来多了几个操作，但换来的是合并时的极端省心。

5.2 冲突解决的标准流程：一步一步来，别慌

真撞上冲突了，不要慌。首先知道一个前提：Git 的冲突并不是丢数据，只是把人类该做的决策暂时交还给你。标准操作流程如下。

第一步，先同步主干到自己的分支，触发合并。

git checkout main git pull origin main git checkout feature/order-export-excel git merge main

当 Git 提示冲突时，它会把冲突文件里的两边代码都呈现出来，用特殊的分隔符标记。打开文件，你会看到类似于这样的结构：

<<<<<<< HEAD // 当前分支（feature/order-export-excel）上的代码 System.out.println("我的导出订单功能"); ======= // 传入分支（main）的代码 System.out.println("我先有的导出 Excel 功能"); >>>>>>> main

你需要做的事情，是决定保留哪一边，还是两边整合一下，然后把三行分隔符和不需要的内容统统删掉，留下一段干净正确的代码。

第二步，处理完所有冲突文件，逐一保存之后，用 git add 标记为已解决。

git add src/main/java/com/yourcompany/order/OrderService.java git commit -m "merge: 合并 main 分支到 feature/order-export-excel，解决导出逻辑冲突"

注意，合并冲突解决之后，提交信息是带merge上下文意义的，录制时好好说是合入主干代码，不要只有一句“解决冲突”就完事了。

第三步，冲突解决后立即自测。

合并动作很隐蔽的一个危险在于：编译器不会告诉你逻辑是否出错，它只保证语法合并对了。冲突是我们人工合并两边的逻辑，极有可能出现两边代码逻辑是独立的、但拼起来失去原有语义的情况。所以合并一旦结束，务必至少跑一遍相关单测、本地构建，确认关键功能没有因为合并而受到破坏。

还有一件事提醒新人：冲突解决过程中不要顺手做额外的功能改动。你现在的角色是调解员，不是开发者。在合并期间夹带新功能，会让后面的回溯非常困难。

5.3 常见异常场景排查速查表

结合这么多年的观察，我挑了几个新人提问率最高的问题，合并成一张速查表。你遇到问题时先对着表格看一遍，多半能自己搞定。

这几点你要是都感知到了，Git 团队开发基本就已入门。剩下的都是在实际操作中积累手感的问题——多踩几次坑并自己排查，印象会深得多。

5.4 新人的心态建设：接受低效，保持透明

最后一段讲点技术之外的事。新人用 Git 时常有的心理负担是：怕自己动作慢、怕总在问同事问题、怕 merge 冲突被别人觉得自己菜。我可以明确告诉你，这些担忧非常普遍，每个人刚开始都一样。

但你会发现，团队的老同事对一个新人的接纳程度，往往取决于一个态度：当你遇到自己搞不定的问题时，是不是及时暴露、及时求助。我见过两类新人，一类吭哧吭哧自己搜解决方案憋了几个小时没进展，另一类发现自己卡住二十分钟就去问旁边的老同事先拉通阻塞再继续。谁更受团队欢迎、成长更快？几乎没有例外，是后者。

具体到 Git 操作上，就是：

• 宁可多问一句“我们团队的合并策略是 merge 还是 rebase”，也不要按网上教程任意发挥，搞完之后仓库历史风格跟团队完全不同。
• 宁可初期慢一点、每步看一眼git status确认自己在哪儿，也不要凭感觉敲命令然后看 log 一脸蒙。
• 宁可 commit 写得啰嗦些、信息充足些，也不要为了显得简洁，写一个只有自己能看懂的缩写。

Git 是工具，不是考核。团队更在意的是协作结果——代码是否及时合入、主干是否保持稳定、团队是否因为你的操作而降低了效率。你只要把这个核心目标放在心上，把流程跑熟，剩下的技术细节都能在真实项目中快速补齐。

6. 实操三个月之后，我建议你回看这几件事

如果运气好，你在这家公司待够三个月，你一定会在某一次操作中，体会到这篇文章前面所有内容到底在讲什么。到那时候再回过头来复盘，你会对自己的成长有个清晰的感知。

复查自己的提交记录。用git log --author=<你的名字> --oneline看看自己提交了哪些 commit，信息是否规范、粒度是否合理、有没有出现于是前后矛盾的一堆碎片提交。如果你发现自己已经能稳定地写出结构良好的提交记录，恭喜你，你已经跨过了“会用 Git”的坎，开始“用 Git 表达你的开发过程”了。

再回看一次你处理过的冲突。Git 的reflog记录了你每一次操作。看看你哪次冲突最惨烈、哪个步骤最多余，复盘当时如果换一种方式会不会更好。这个过程其实就是老手和新手最大的差异：老手不是不会犯错，而是犯过一次之后，再也不会用同样的方式犯第二次。

最后给你一条很实在的建议：把你学习和踩坑的过程记录下来。不用写得花哨，就在个人笔记里记一条：“合并冲突时要先看三行分隔符的位置再动手，别急着删”“revert 的是提交，reset 回的是状态”这种小笔记。半年后回头看，这些才是职业生涯一开始最宝贵的积累。

Git 本身不是目的，它只是团队协作的载体。掌握了这门工具和它背后的协作规范，你才能真正把“一个人写代码”的思维切换成“和一群人把一个项目长期维持下去”的思维。这也是软件开发这件事比单纯写码更迷人的那部分——它是一种需要大量沟通、协调和共识的工程活动，而 Git 的冷冰冰的指令背后，恰恰是团队不断磨合、共同维护代码质量的日常。