GitHub 上手容易但真正把它用成“团队协作工具”而不是“代码网盘”中间隔着一整套规范和流程。我见过太多项目代码往 main 分支上一股脑推同事之间互相覆盖、冲突满天飞最后只能靠口头沟通“你等一下再 push”。这篇文章就针对多人队伍合作这个场景把仓库权限、分支模型、Pull Request、冲突处理、Issue 管理这些核心环节一次性讲透适合刚组建团队、或者已经在用 GitHub 但总觉得协作不顺畅的开发者参考。1. 团队仓库的初始化与权限设计多人协作的第一件事不是写代码而是把仓库结构和权限规则定好。这一步没做扎实后面几十个 commit 全挤在一个分支上谁也分不清哪次提交是谁的需求。1.1 搭建团队仓库前要想清楚的事先回答三个问题代码放谁名下、谁能直接推送、什么时候用 fork。第一种方式直接在组织Organization下建仓库团队成员统一加到组织里。这种方式适合内部项目大家有明确的读写权限操作路径最短。第二种方式把仓库建在某个成员账号下其他成员以 Collaborator 身份加入适合小团队试水不过后续换负责人时转移所有权比较麻烦我建议只要有长期维护的打算就直接开组织账号。权限粒度上GitHub 默认给的是 Write、Triage、Maintain、Admin 几档。团队实用配置一般是核心维护者分配 Maintain 或 Admin负责合并 PR、管理设置普通开发给 Write能推送分支、能发起 PR但推不动受保护分支产品、测试或者偶尔来看代码的人给 Read 就够了。注意权限宁紧勿松。默认情况下所有能 Write 的人都能 push 到任何分支如果你不想让新人直接把半成品推到主干上必须在分支保护里做限制这一步很多人忽略了等到出事才想起来。1.2 分支保护规则怎么配置分支保护Branch Protection Rules是多人协作的“红绿灯”没有它main 分支谁都能推合入质量全靠自觉。在仓库的 Settings - Branches - Add rule 里配置我建议至少设置这三项Require pull request reviews before merging必须经过 PR 审查才能合入。建议把 Required number of approvals 设成 1两个人小队就设 1超过 5 人的核心分支设 2太多反而拖慢节奏。Require status checks to pass before merging绑定 CI比如 GitHub Actions测试不过不许合入。这一步能把非常多的低级回归挡在门外。Do not allow bypassing the above settings别让管理员绕过检查否则规则形同虚设。管理员想强推的时候先问他一句是规则错了还是代码错了我自己踩过的一个坑是早期图省事分支保护只勾了“审查”没勾“状态检查”结果队友合入的代码把构建搞挂了。后来加上 CI 检查类似问题基本绝迹。分支保护不是用来刁难人的是替团队守门的。2. 多人协作的分支模型与命名规范仓库结构定好了接下来是所有冲突的根源分支怎么建、怎么命名、怎么合。分支模型不统一十个人的团队能发展出十种 commit 风格那画面太美。2.1 常用分支模型的选型思路开源社区玩的最多的两套模型是 Git Flow 和 GitHub Flow。Git Flow 有 master、develop、feature、release、hotfix 五种常驻分支生命周期复杂适合版本节奏固定、需要长期维护多个版本的软件项目比如发版 App。但它的学习成本高对一个小团队来说往往过度设计。GitHub Flow 就简洁得多只有一个常驻分支main所有开发都从 main 切出带描述性的功能分支完成以后通过 PR 合回 main。它假设你的团队能持续集成、持续上线每次合并到 main 都是可部署状态。我个人的建议是绝大多数中小团队直接选 GitHub Flow。原因很实际分支越少心智负担越低冲突概率也越小。只有当你确定要同时维护 2.0、3.0 两个版本线再考虑引入 Git Flow 或者它的简化变体。2.2 分支命名、Commit 信息与 PR 规范分支命名看起来是小事实际上决定了你浏览远程分支列表时能不能一眼定位。推荐用“类型/描述”的格式feature/login-page新功能fix/payment-timeout缺陷修复refactor/user-service重构docs/readme-update文档Commit 信息我强烈建议带上关联编号或者语义前缀比如feat: 增加登录页表单校验、fix: 修复支付超时未提示问题一看就懂。PR 的标题和描述同样要规范化。一个合格的 PR 描述应该包含改了什么、为什么改、怎么测试。别小看这几句话它不是写给审核人看的是写给三个月后的自己看的。实操心得分支生命周期要短。一个功能分支超过三天还没合入大概率是需求切碎了或者卡住了这时候应该主动同步 main 取消掉过大的分支把任务拆小。功能分支不是保险箱放得越久合并成本越高。3. 从开发到合入的完整 Pull Request 流程Pull Request 是 GitHub 多人协作的灵魂它不只是一个合并操作而是一次集代码审查、讨论、自动化检查于一体的标准化流程。3.1 本地开发的正确姿势第一步永远是同步。任何开发之前先执行git checkout main git pull origin main git checkout -b feature/login-page这里有个很多人犯的错误直接从自己过时的本地 main 上切分支写代码。结果写了两天远程 main 已经变了好几轮一 merge 就是铺天盖地的冲突。正确做法是每次切新分支前都确保本地 main 和远程是一致的。开发过程中建议养成“小步提交”的习惯。功能写完一个完整的小单元就 commit 一次别攒到最后一次性交一旦要回退或者 bisect 定位问题时小提交会帮你节省大量时间。3.2 Code Review 与 CI 检查写完代码推到远程分支在 GitHub 页面上点击 New pull request选择你的分支合入 main填好标题和描述。这时候真正的“多人协作”才开始。Code Review 的核心原则是审查逻辑是否清晰、命名是否达意、边界情况是否覆盖而不是吹毛求疵。给队友评审时我看到过最高效的做法是提出“建议级别”的修改请求在 GitHub 的 review 里选择 Request changes 或者 Comment并且在代码行内直接留言比笼统说一句“这里逻辑有问题”有效得多。CI 检查方面我之前用 GitHub Actions 在 PR 上跑 lint 和单测配置非常简单在.github/workflows/ci.yml里写上触发条件name: CI on: pull_request: branches: [main] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - run: npm ci - run: npm test配置完之后每个 PR 都会自动跑一遍检查红色状态成了拦截不合规代码最有效的一道闸门。3.3 合并策略怎么选在 PR 合并按钮旁边有三个选项Create a merge commit、Squash and merge、Rebase and merge。经常团队里几个人默认选项各不同有人留下 merge commit 的历史有人一条 squash 把十几个 commit 压成一个历史乱得一塌糊涂。我的建议很直接策略历史形态适用场景Merge commit保留所有提交有额外合并节点需要完整保留开发过程时Squash and merge压缩为一个提交历史清爽功能分支上的提交比较琐碎时Rebase and merge线性历史无合并节点追求简洁线性的提交历史团队最好在 GitHub 仓库设置里直接禁用其中两种只留一种默认选项省得每次合并时有人纠结。我一般给团队默认开 Squash and merge功能分支的细碎提交没必要全部保留在 main 历史里。4. 冲突处理多人改同一片代码多人协作不可能完全避开冲突这不是灾难是常态。关键在于学会用系统的流程减少冲突以及冲突来了不慌不忙地解决。4.1 冲突是怎么产生的冲突的本质是同一文件的同一区域被两个人改成了不同内容Git 不知道该听谁的只能把决定权交还给你。举个例子你和同事都改了config.js里的 API 地址字段他先合入了你拉最新代码时 Git 会提示 CONFLICT。这时候不要慌Git 已经把冲突标记留在文件里 feature/your-branch baseURL: https://api.yourservice.com baseURL: https://api-new.another.com main到之间是你当前分支的版本到之间是 main 分支的版本。你要做的是二选一或者合并成一个合理的版本然后删掉这些标记。4.2 解决冲突的实操步骤解决冲突的标准流程# 1. 先把 main 最新的代码拉下来合并到当前分支 git fetch origin git merge origin/main # 2. 打开冲突文件手动修正逻辑 # 3. 确认无误后标记为已解决并继续 git add config.js git merge --continue这里有个重要的细节别直接修完全部冲突再一次性 merge --continue而是每解决一个文件就 add 一个文件这样可以保持清醒避免重复改动。如果冲突文件特别多或者你自己改动的部分已经被同事大规模重构了一个更稳妥的办法是放弃直接合并用 rebase 把分支基于最新 main 重新“变基”git rebase origin/mainrebase 的好处是让提交历史更干净但它会改写提交节点如果功能分支同时被别人协作有共享历史就不要乱 rebase否则会把队友的提交搞得一团糟。判断标准就一条这个分支只有你自己在用就随便 rebase有别人在碰老老实实用 merge。实战过的经验之谈冲突最频繁的文件往往不是“代码文件”而是package-lock.json、podfile.lock这类锁文件。处理这类文件时不要用手工合并正确做法是重新执行包管理器的安装命令让它自己生成最新锁定状态。手动改锁文件基本等于给自己埋雷。5. 用 Issues 和 Projects 把协作搬到明面上很多团队把 GitHub 当成代码托管平台Issue 和 Projects 一块完全闲置项目管理工具则另外用一套。这非常可惜因为把任务、Bug 和代码提交挂在一起能省掉大量“这个需求做到哪了”的沟通成本。5.1 写好 Issue 与模板一个高质量的 Issue 应该让读者在 30 秒内知道三件事背景是什么、要做什么、完成标准是什么。Bug 类 Issue 我习惯用这样的模板环境版本操作系统、浏览器、Node 版本等复现步骤Step 1 / Step 2 / Step 3预期行为 vs 实际行为截图或报错日志需求类 Issue 则用用户故事作为谁想要什么为了什么验收标准完成时必须满足哪些条件关联文件或模块在 GitHub 仓库的 Settings - General - Issues 里可以通过设置 Issue templates 把这些模板固化下来以后新建 Issue 时自动弹出团队成员填写时不会漏项。团队人员流动快的阶段这招能大大降低沟通成本。5.2 看板管理与自动化GitHub 的 Projects现在叫 Projects以前叫 Projects Beta提供看板视图把 Issue 按状态拖拽流转和代码完全打通。团队里哪怕只用最基础的三列To do / In progress / Done也比一堆人纯口头沟通高效得多。更进一步可以用 GitHub Actions 做 Issue 自动化和标签联动。比如 PR 里写了Closes #12合入之后 Issue 自动关闭这算是最常用的一条链路。我自己还配过一个简单流程新建 Issue 时根据标题关键词自动打上 bug 或 feature 标签省了手动分类的时间。看板这东西核心不是工具而是“状态必须由负责人主动更新”。建议在团队例会里花两分钟过一遍看板谁的任务卡住了、谁的在 review 环节滞留过久一眼就看得出来。它把每个人的工作进度透明化是团队协作里最能建立信任感的环节。6. 团队协作常见问题与排查技巧最后这部分我把实际带团队过程中反复出现的高频问题整理成速查表并分享几条让协作流程真正落地的经验。6.1 高频问题速查表现象原因处理方法push 被拒绝non-fast-forward远程有本地没有的提交先 git pull --rebase 再重新 push误提交到 main 分支没切功能分支就提交git reset --soft 回退切分支后重新提交PR 里混入了多余提交从旧 main 切分支导致用 git rebase -i 整理提交或重新基于最新 main 切分支解决冲突时误删队友代码只看了自己改的部分解决后找原修改人 review 一次冲突结果忘记关掉已合入的功能分支更新流程不完整在 GitHub 合并页面勾选自动删除分支提交信息没有关联需求团队规范没落地PR 标题写明关联 Issue 编号用模板强制其中第一个问题最经典。git push被拒绝时通常是因为你忘了 pull 或者 pull 之后本地分支已经落后。这时候先执行git pull --rebase把自己的提交暂时“摘下来”等远程提交落地后再重新放上去历史就干净了。6.2 团队协作中的坑与落地经验带过几次小队协作之后我越来越清楚一件事流程不是越多越好而是越容易被遵守越好。第一个经验是少即是多。刚建团队的时候别一口气上十几种规则先把分支保护、PR 审查、提交前缀这三件事做好等团队真的适应了再逐步加码。我见过有团队第一天就上全套 Git Flow 加严格 Commit lint结果新人一周内都在研究分支代码没写几行这种过度工程化很快会被大家用脚投票。第二个经验是把规则固化到工具里不要靠自觉。比如强制提交信息格式可以装 commitlint 在 CI 里跑强制审查可以在分支保护里配。人只负责做判断规则交给工具才能真正长久执行下去。第三个经验是定期复盘仓库状态。我习惯每两周看一眼分支列表该合没合的功能分支督促一下已经死掉的旧分支清理掉。别小看这个习惯一个积累了半年的仓库光僵尸分支和过时的 PR 就能让新成员望而却步。多人协作的本质从来不是把一堆命令背得滚瓜烂熟而是建立一套大家共识的流程让每个人的代码能够以可预期的方式汇合到一起。GitHub 只是把这些流程落地的载体分支保护、PR 审查、Issue 跟踪这些功能单拎出来都很简单但组合在一起就能让一个团队从“各写各的、最后痛苦地合并”变成“持续交付、小步快跑”的状态。把这套流程跑顺以后你会发现冲突变少了代码质量稳了新人上手也快了——这才是团队协作工具真正的价值所在。
GitHub 团队协作全指南：分支保护、Pull Request 与冲突处理实战
GitHub 上手容易但真正把它用成“团队协作工具”而不是“代码网盘”中间隔着一整套规范和流程。我见过太多项目代码往 main 分支上一股脑推同事之间互相覆盖、冲突满天飞最后只能靠口头沟通“你等一下再 push”。这篇文章就针对多人队伍合作这个场景把仓库权限、分支模型、Pull Request、冲突处理、Issue 管理这些核心环节一次性讲透适合刚组建团队、或者已经在用 GitHub 但总觉得协作不顺畅的开发者参考。1. 团队仓库的初始化与权限设计多人协作的第一件事不是写代码而是把仓库结构和权限规则定好。这一步没做扎实后面几十个 commit 全挤在一个分支上谁也分不清哪次提交是谁的需求。1.1 搭建团队仓库前要想清楚的事先回答三个问题代码放谁名下、谁能直接推送、什么时候用 fork。第一种方式直接在组织Organization下建仓库团队成员统一加到组织里。这种方式适合内部项目大家有明确的读写权限操作路径最短。第二种方式把仓库建在某个成员账号下其他成员以 Collaborator 身份加入适合小团队试水不过后续换负责人时转移所有权比较麻烦我建议只要有长期维护的打算就直接开组织账号。权限粒度上GitHub 默认给的是 Write、Triage、Maintain、Admin 几档。团队实用配置一般是核心维护者分配 Maintain 或 Admin负责合并 PR、管理设置普通开发给 Write能推送分支、能发起 PR但推不动受保护分支产品、测试或者偶尔来看代码的人给 Read 就够了。注意权限宁紧勿松。默认情况下所有能 Write 的人都能 push 到任何分支如果你不想让新人直接把半成品推到主干上必须在分支保护里做限制这一步很多人忽略了等到出事才想起来。1.2 分支保护规则怎么配置分支保护Branch Protection Rules是多人协作的“红绿灯”没有它main 分支谁都能推合入质量全靠自觉。在仓库的 Settings - Branches - Add rule 里配置我建议至少设置这三项Require pull request reviews before merging必须经过 PR 审查才能合入。建议把 Required number of approvals 设成 1两个人小队就设 1超过 5 人的核心分支设 2太多反而拖慢节奏。Require status checks to pass before merging绑定 CI比如 GitHub Actions测试不过不许合入。这一步能把非常多的低级回归挡在门外。Do not allow bypassing the above settings别让管理员绕过检查否则规则形同虚设。管理员想强推的时候先问他一句是规则错了还是代码错了我自己踩过的一个坑是早期图省事分支保护只勾了“审查”没勾“状态检查”结果队友合入的代码把构建搞挂了。后来加上 CI 检查类似问题基本绝迹。分支保护不是用来刁难人的是替团队守门的。2. 多人协作的分支模型与命名规范仓库结构定好了接下来是所有冲突的根源分支怎么建、怎么命名、怎么合。分支模型不统一十个人的团队能发展出十种 commit 风格那画面太美。2.1 常用分支模型的选型思路开源社区玩的最多的两套模型是 Git Flow 和 GitHub Flow。Git Flow 有 master、develop、feature、release、hotfix 五种常驻分支生命周期复杂适合版本节奏固定、需要长期维护多个版本的软件项目比如发版 App。但它的学习成本高对一个小团队来说往往过度设计。GitHub Flow 就简洁得多只有一个常驻分支main所有开发都从 main 切出带描述性的功能分支完成以后通过 PR 合回 main。它假设你的团队能持续集成、持续上线每次合并到 main 都是可部署状态。我个人的建议是绝大多数中小团队直接选 GitHub Flow。原因很实际分支越少心智负担越低冲突概率也越小。只有当你确定要同时维护 2.0、3.0 两个版本线再考虑引入 Git Flow 或者它的简化变体。2.2 分支命名、Commit 信息与 PR 规范分支命名看起来是小事实际上决定了你浏览远程分支列表时能不能一眼定位。推荐用“类型/描述”的格式feature/login-page新功能fix/payment-timeout缺陷修复refactor/user-service重构docs/readme-update文档Commit 信息我强烈建议带上关联编号或者语义前缀比如feat: 增加登录页表单校验、fix: 修复支付超时未提示问题一看就懂。PR 的标题和描述同样要规范化。一个合格的 PR 描述应该包含改了什么、为什么改、怎么测试。别小看这几句话它不是写给审核人看的是写给三个月后的自己看的。实操心得分支生命周期要短。一个功能分支超过三天还没合入大概率是需求切碎了或者卡住了这时候应该主动同步 main 取消掉过大的分支把任务拆小。功能分支不是保险箱放得越久合并成本越高。3. 从开发到合入的完整 Pull Request 流程Pull Request 是 GitHub 多人协作的灵魂它不只是一个合并操作而是一次集代码审查、讨论、自动化检查于一体的标准化流程。3.1 本地开发的正确姿势第一步永远是同步。任何开发之前先执行git checkout main git pull origin main git checkout -b feature/login-page这里有个很多人犯的错误直接从自己过时的本地 main 上切分支写代码。结果写了两天远程 main 已经变了好几轮一 merge 就是铺天盖地的冲突。正确做法是每次切新分支前都确保本地 main 和远程是一致的。开发过程中建议养成“小步提交”的习惯。功能写完一个完整的小单元就 commit 一次别攒到最后一次性交一旦要回退或者 bisect 定位问题时小提交会帮你节省大量时间。3.2 Code Review 与 CI 检查写完代码推到远程分支在 GitHub 页面上点击 New pull request选择你的分支合入 main填好标题和描述。这时候真正的“多人协作”才开始。Code Review 的核心原则是审查逻辑是否清晰、命名是否达意、边界情况是否覆盖而不是吹毛求疵。给队友评审时我看到过最高效的做法是提出“建议级别”的修改请求在 GitHub 的 review 里选择 Request changes 或者 Comment并且在代码行内直接留言比笼统说一句“这里逻辑有问题”有效得多。CI 检查方面我之前用 GitHub Actions 在 PR 上跑 lint 和单测配置非常简单在.github/workflows/ci.yml里写上触发条件name: CI on: pull_request: branches: [main] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - run: npm ci - run: npm test配置完之后每个 PR 都会自动跑一遍检查红色状态成了拦截不合规代码最有效的一道闸门。3.3 合并策略怎么选在 PR 合并按钮旁边有三个选项Create a merge commit、Squash and merge、Rebase and merge。经常团队里几个人默认选项各不同有人留下 merge commit 的历史有人一条 squash 把十几个 commit 压成一个历史乱得一塌糊涂。我的建议很直接策略历史形态适用场景Merge commit保留所有提交有额外合并节点需要完整保留开发过程时Squash and merge压缩为一个提交历史清爽功能分支上的提交比较琐碎时Rebase and merge线性历史无合并节点追求简洁线性的提交历史团队最好在 GitHub 仓库设置里直接禁用其中两种只留一种默认选项省得每次合并时有人纠结。我一般给团队默认开 Squash and merge功能分支的细碎提交没必要全部保留在 main 历史里。4. 冲突处理多人改同一片代码多人协作不可能完全避开冲突这不是灾难是常态。关键在于学会用系统的流程减少冲突以及冲突来了不慌不忙地解决。4.1 冲突是怎么产生的冲突的本质是同一文件的同一区域被两个人改成了不同内容Git 不知道该听谁的只能把决定权交还给你。举个例子你和同事都改了config.js里的 API 地址字段他先合入了你拉最新代码时 Git 会提示 CONFLICT。这时候不要慌Git 已经把冲突标记留在文件里 feature/your-branch baseURL: https://api.yourservice.com baseURL: https://api-new.another.com main到之间是你当前分支的版本到之间是 main 分支的版本。你要做的是二选一或者合并成一个合理的版本然后删掉这些标记。4.2 解决冲突的实操步骤解决冲突的标准流程# 1. 先把 main 最新的代码拉下来合并到当前分支 git fetch origin git merge origin/main # 2. 打开冲突文件手动修正逻辑 # 3. 确认无误后标记为已解决并继续 git add config.js git merge --continue这里有个重要的细节别直接修完全部冲突再一次性 merge --continue而是每解决一个文件就 add 一个文件这样可以保持清醒避免重复改动。如果冲突文件特别多或者你自己改动的部分已经被同事大规模重构了一个更稳妥的办法是放弃直接合并用 rebase 把分支基于最新 main 重新“变基”git rebase origin/mainrebase 的好处是让提交历史更干净但它会改写提交节点如果功能分支同时被别人协作有共享历史就不要乱 rebase否则会把队友的提交搞得一团糟。判断标准就一条这个分支只有你自己在用就随便 rebase有别人在碰老老实实用 merge。实战过的经验之谈冲突最频繁的文件往往不是“代码文件”而是package-lock.json、podfile.lock这类锁文件。处理这类文件时不要用手工合并正确做法是重新执行包管理器的安装命令让它自己生成最新锁定状态。手动改锁文件基本等于给自己埋雷。5. 用 Issues 和 Projects 把协作搬到明面上很多团队把 GitHub 当成代码托管平台Issue 和 Projects 一块完全闲置项目管理工具则另外用一套。这非常可惜因为把任务、Bug 和代码提交挂在一起能省掉大量“这个需求做到哪了”的沟通成本。5.1 写好 Issue 与模板一个高质量的 Issue 应该让读者在 30 秒内知道三件事背景是什么、要做什么、完成标准是什么。Bug 类 Issue 我习惯用这样的模板环境版本操作系统、浏览器、Node 版本等复现步骤Step 1 / Step 2 / Step 3预期行为 vs 实际行为截图或报错日志需求类 Issue 则用用户故事作为谁想要什么为了什么验收标准完成时必须满足哪些条件关联文件或模块在 GitHub 仓库的 Settings - General - Issues 里可以通过设置 Issue templates 把这些模板固化下来以后新建 Issue 时自动弹出团队成员填写时不会漏项。团队人员流动快的阶段这招能大大降低沟通成本。5.2 看板管理与自动化GitHub 的 Projects现在叫 Projects以前叫 Projects Beta提供看板视图把 Issue 按状态拖拽流转和代码完全打通。团队里哪怕只用最基础的三列To do / In progress / Done也比一堆人纯口头沟通高效得多。更进一步可以用 GitHub Actions 做 Issue 自动化和标签联动。比如 PR 里写了Closes #12合入之后 Issue 自动关闭这算是最常用的一条链路。我自己还配过一个简单流程新建 Issue 时根据标题关键词自动打上 bug 或 feature 标签省了手动分类的时间。看板这东西核心不是工具而是“状态必须由负责人主动更新”。建议在团队例会里花两分钟过一遍看板谁的任务卡住了、谁的在 review 环节滞留过久一眼就看得出来。它把每个人的工作进度透明化是团队协作里最能建立信任感的环节。6. 团队协作常见问题与排查技巧最后这部分我把实际带团队过程中反复出现的高频问题整理成速查表并分享几条让协作流程真正落地的经验。6.1 高频问题速查表现象原因处理方法push 被拒绝non-fast-forward远程有本地没有的提交先 git pull --rebase 再重新 push误提交到 main 分支没切功能分支就提交git reset --soft 回退切分支后重新提交PR 里混入了多余提交从旧 main 切分支导致用 git rebase -i 整理提交或重新基于最新 main 切分支解决冲突时误删队友代码只看了自己改的部分解决后找原修改人 review 一次冲突结果忘记关掉已合入的功能分支更新流程不完整在 GitHub 合并页面勾选自动删除分支提交信息没有关联需求团队规范没落地PR 标题写明关联 Issue 编号用模板强制其中第一个问题最经典。git push被拒绝时通常是因为你忘了 pull 或者 pull 之后本地分支已经落后。这时候先执行git pull --rebase把自己的提交暂时“摘下来”等远程提交落地后再重新放上去历史就干净了。6.2 团队协作中的坑与落地经验带过几次小队协作之后我越来越清楚一件事流程不是越多越好而是越容易被遵守越好。第一个经验是少即是多。刚建团队的时候别一口气上十几种规则先把分支保护、PR 审查、提交前缀这三件事做好等团队真的适应了再逐步加码。我见过有团队第一天就上全套 Git Flow 加严格 Commit lint结果新人一周内都在研究分支代码没写几行这种过度工程化很快会被大家用脚投票。第二个经验是把规则固化到工具里不要靠自觉。比如强制提交信息格式可以装 commitlint 在 CI 里跑强制审查可以在分支保护里配。人只负责做判断规则交给工具才能真正长久执行下去。第三个经验是定期复盘仓库状态。我习惯每两周看一眼分支列表该合没合的功能分支督促一下已经死掉的旧分支清理掉。别小看这个习惯一个积累了半年的仓库光僵尸分支和过时的 PR 就能让新成员望而却步。多人协作的本质从来不是把一堆命令背得滚瓜烂熟而是建立一套大家共识的流程让每个人的代码能够以可预期的方式汇合到一起。GitHub 只是把这些流程落地的载体分支保护、PR 审查、Issue 跟踪这些功能单拎出来都很简单但组合在一起就能让一个团队从“各写各的、最后痛苦地合并”变成“持续交付、小步快跑”的状态。把这套流程跑顺以后你会发现冲突变少了代码质量稳了新人上手也快了——这才是团队协作工具真正的价值所在。
