“我们四个真是太厉害了”——这句话最近在很多技术群里成了梗多半是几个人合作搞定了某个需求之后在群里互相吹捧时用的。但如果你真在一个开发小组里待过就会知道四个人一起写一个项目能让“团队士气高涨”的绝对不是上线那天的庆功而是从需求拆解到代码合并整个过程居然没出大乱子。一个人写代码难点在“写”四个人写代码难点就变成了“配合”。很多小团队明明人数不多却频繁遇到代码覆盖、冲突解不完、某人的改动悄悄破坏了另一个模块、上线前才发现分支合并错了等问题。这种混乱和人数没有必然关系和“协作方式”有直接关系。这篇文章要解决的就是这件事一个四人规模的小团队怎么用 Git 分支模型、Code Review、自动化检查和持续集成把日常开发从“薛定谔的合并”变成“可预期的流程”。不管你用的是 GitHub、GitLab 还是 Gitee核心方法都通用。1. 团队协作的真正痛点不是代码而是变更叠加先说一个很常见的场景。四个人同时开发一个 Web 项目分工大概是这样A 做用户登录B 做商品列表C 做订单接口D 做管理后台。每个人都觉得自己负责的模块很独立于是都在本地master或main分支上开发。上午还很正常下午问题就来了。A 改了一个工具类B 也在同一个文件里加了方法C 修改了数据库连接配置D 在本地也改了同一个配置。等大家往远程仓库推代码时Git 提示“无法快进推送”于是有人选择git pull结果冲突文件一个接一个。为了尽快解决问题有人直接把冲突全部改成“保留双方代码”结果项目编译都过不了。这种事经历几次之后团队就会形成一种默契谁也不敢动公共文件改之前先吼一声。但这种靠嗓门维持的协作规模稍微大一点就会失效。从根上讲问题出在三个方面没有清晰的分支策略。所有人都在一条主干上直接开发彼此的变更没有隔离。代码评审缺失。改动直接推到主干没有第二个人确认逻辑问题只能在运行时暴露。没有自动化验证关卡。合并之前没有编译、测试、静态检查冲突和低级错误只能靠人肉发现。所以要解决“四个人开发乱成一锅粥”的问题第一步不是写更多代码而是建立一套变更管理流程。1.1 “分支隔离 评审合并 自动检查”这套组合要解决什么用一句话概括让每一个人的改动先在自己的空间里完成经过验证和评审再回到主干。这套组合里各部分的职责很清晰环节解决什么问题通俗解释功能分支变更互相干扰每个人在独立分支上开发主干保持随时可发布的状态Code Review错误提前发现合入主干前至少另一个人看过改动自动检查低级错误拦截编译、测试、静态检查全自动跑不再靠自觉合并策略历史清晰、可回滚所有合入记录明确出了问题可以回退到固定节点这套流程本质上是在给“团队协作”建立缓冲区。你的代码先在分支上自证“能编译、测试通过、有人审过”才有资格进入主干。这不只是规范也是让“我们四个真是太厉害了”这句话多说几次的技术保障。2. 核心概念分支、提交、合并、远程协作的基础认知在配置流程之前先把几个容易混淆的概念理清楚。因为很多协作混乱其实是对 Git 对象和工作流理解不到位。2.1 分支不是文件夹是“可移动的指针”新手容易把分支理解成代码的“副本”其实 Git 分支本质上是一个指向提交的指针。创建分支非常轻量只是新建一个指针。当你在分支上提交时指针才会向前移动。理解这一点有什么用它决定了“切换分支”“合并分支”这些操作并不神秘也决定了你可以放心地多创建分支而不用怕占用太多空间。2.2 提交是“快照”不是“差异”Git 的提交不是保存当前版本和上一版本的差异而是保存当前所有文件的一个快照。为了节省空间Git 会复用没有变化的文件。这意味着每次提交都应该是一个逻辑完整的变更而不是“改一下再改一下”的碎碎念提交。提交信息写得清楚将来回滚、查问题会省很多力气。2.3 合并、变基、快进合并有什么区别合并merge会生成一个额外的合并提交保留两个分支的历史轨迹。变基rebase则是把你的提交“挪”到目标分支的最新提交后面历史像一条直线。两者没有绝对的谁更好看团队取舍操作历史形态优点缺点git merge有分叉、有合并节点保留真实开发过程回滚时能看出合并点历史复杂有大量 merge commitgit rebase线性历史看着干净方便git bisect定位问题改写了提交历史多人协作时若已推送需谨慎还有一个“快进合并”fast-forward。当你基于当前主干最新提交创建分支主干没有新的提交时合并分支可以直接把指针前移不生成合并提交。很多团队的 PR 合并不采用这种方式而是强制生成 merge commit就是为了保留一次合入记录。2.4 远程仓库不是“云盘”远程仓库remote更像是一个“约定的中间节点”所有人往这里推拉代码。origin只是默认的远程仓库名。常见的协作问题——比如rejected推送失败——本质上是因为远程分支上有你本地没有的提交Git 不允许强行覆盖除非你用了push -f但这很危险。理解了这些底层概念后面的流程设计就好理解了。3. 环境准备搭好 Git 与远程仓库的基础配置这里假设你用的是 Linux/macOS 或 Windows Git Bash。版本方面Git 2.x 都可以如果太老建议升级到 2.30 以上因为后续的一些分支命令更友好。本文演示的命令以通用 Git 命令为准不依赖特定托管平台。3.1 安装与基础配置git --version如果没安装参照对应系统安装即可。装完之后先设置身份信息因为每次提交都会记录这些信息git config --global user.name Your Name git config --global user.email yournameexample.com推荐设置默认分支名和提交时的默认编辑器git config --global init.defaultBranch main git config --global core.editor vim3.2 创建远程仓库并克隆到本地这里以常见的 Git 托管平台为例。假设你在平台上创建了一个空仓库地址是gitexample.com:team/four-dev.git那么克隆到本地git clone gitexample.com:team/four-dev.git cd four-dev如果你的仓库已经有文件需要在克隆前确认你本地是否清空了目标目录避免覆盖。3.3 设置 SSH 密钥以 GitHub/GitLab 通用方式为例为了避免每次推送都输入密码推荐配置 SSH key。先在本地生成ssh-keygen -t ed25519 -C yournameexample.com一路回车生成的公钥默认在~/.ssh/id_ed25519.pub。复制内容添加到 Git 托管平台的 SSH Keys 设置页面然后验证ssh -T gitexample.com看到欢迎信息说明连接成功。这一步不是必须的但能避免反复输入账号密码也让 CI 等自动化工具更容易接入。4. 核心流程拆解四人团队的分支与合并规范现在进入正题。我们把四人团队的分工定义成一组典型角色然后设计一套简单但完整的分支协作流程。这套流程不是教科书式的 Git Flow而是更适合小团队的轻量模型。4.1 分支模型设计主干分支main始终保持可发布状态。开发分支每个人从main检出自己的功能分支命名建议为feature/xxx、fix/xxx、docs/xxx等。例如main ├── feature/user-login (A 负责) ├── feature/goods-list (B 负责) ├── feature/order-api (C 负责) └── feature/admin-dashboard (D 负责)每完成一个小任务就可以向main发起合并请求。这里的关键判断是不要在 feature 分支之间互相合并。四个人不需要共享“开发分支”各干各的然后统一合回main。如果确实有公共代码需要先落地就让一个人先把它合到main其他人再拉取main的最新代码。4.2 一次完整的开发周期以 A 开发“用户登录”这个功能为例从最新main创建本地分支git checkout main git pull origin main git checkout -b feature/user-login开发和本地提交git add . git commit -m feat: add user login API提交信息建议遵循约定式提交风格feat、fix、docs、refactor等后面会讲。推送到远程git push -u origin feature/user-login在托管平台上发起 Pull Request / Merge Request目标分支选main标题写清楚改动意图描述里补充“为什么改”“怎么测试”。其他成员进行 Code ReviewCI 自动跑测试。Review 通过后点击合并。4.3 如何保持功能分支和 main 同步如果开发周期较长A 每天会拉一次main的最新代码到自己分支。两种做法这里推荐用 rebase 保持历史线性git checkout feature/user-login git fetch origin main git rebase origin/main如果遇到冲突Git 会停在冲突提交上。此时需要手动解决冲突然后git add . git rebase --continue这里有个重要提醒**rebase 改写提交历史所以只应对尚未被其他人共享的分支执行。**如果 A 已经把这个 feature 分支推到远程并且和 B 说“你帮我在这个分支上改一下”那就不适合 rebase应该改用 merge 或者先和团队确认好统一策略。之所以在同步main时更推荐 rebase是因为 feature 分支还没合入主干它的历史本来就可以整理合入后主干可以保持近似线性的历史定位问题更简单。4.4 合并到 main 的几种策略怎么选大多数托管平台在合并 PR 时提供选项策略效果适用场景Merge commit保留一次合并记录和全部历史分叉希望看到“合入动作”的团队Squash and merge把 PR 内多个提交压缩成一个希望主干历史整洁一个功能一个提交Rebase and merge把提交线性地接到目标分支想避免 merge commit同时保留每个提交对于四人小团队我个人建议在main分支上使用Squash and merge。因为它把整个功能分支压缩成一个提交主干非常干净。缺点是你丢失了 PR 内的中间提交细节但对小项目来说feat(user-login): ...这一个提交足够回滚和定位问题。5. 完整示例从空仓库到一次协作合并下面我们实际跑一遍流程。以 Python Flask 项目为例但重点不是 Flask而是协作流程。5.1 初始化项目在托管平台创建空仓库team-four-demo然后本地初始化mkdir team-four-demo cd team-four-demo git init git checkout -b main创建.gitignore避免把虚拟环境、缓存等文件提交进去。# 文件路径.gitignore __pycache__/ *.py[cod] .venv/ venv/ .env .idea/ .vscode/ *.log创建 README# team-four-demo 四人协作示例项目创建初始requirements.txtflask3.0.0 pytest7.4.0创建最小应用# 文件路径app.py from flask import Flask app Flask(__name__) app.route(/health) def health(): return {status: ok}提交并推送到远程git add . git commit -m chore: init project git remote add origin gitexample.com:team/team-four-demo.git git push -u origin main5.2 A 添加登录接口A 在本地创建功能分支git checkout main git pull origin main git checkout -b feature/user-login在app.py中添加登录接口# 文件路径app.py from flask import Flask, request, jsonify app Flask(__name__) users { alice: 123456, bob: 654321, } app.route(/health) def health(): return {status: ok} app.route(/login, methods[POST]) def login(): data request.get_json() username data.get(username) password data.get(password) if users.get(username) password: return jsonify({code: 0, message: success}) return jsonify({code: 1001, message: invalid username or password}), 401同时添加测试文件# 文件路径test_app.py import json import pytest from app import app pytest.fixture def client(): app.config[TESTING] True with app.test_client() as client: yield client def test_health(client): resp client.get(/health) assert resp.status_code 200 assert resp.get_json() {status: ok} def test_login_success(client): resp client.post( /login, datajson.dumps({username: alice, password: 123456}), content_typeapplication/json, ) assert resp.status_code 200 assert resp.get_json()[code] 0 def test_login_fail(client): resp client.post( /login, datajson.dumps({username: alice, password: wrong}), content_typeapplication/json, ) assert resp.status_code 401 assert resp.get_json()[code] 1001提交git add app.py test_app.py git commit -m feat: add login API and tests git push -u origin feature/user-login5.3 B 创建商品列表接口B 的操作路径完全一样git checkout main git pull origin main git checkout -b feature/goods-list在app.py中添加商品列表GOODS [ {id: 1, name: apple, price: 5.0}, {id: 2, name: banana, price: 3.5}, ] app.route(/goods, methods[GET]) def goods_list(): return jsonify({code: 0, data: GOODS})提交并推送git add app.py git commit -m feat: add goods list API git push -u origin feature/goods-list这里可以看到A 和 B 都修改了app.py但由于处在不同分支互不干扰。等 A 的 PR 先合入mainB 就需要把main的最新代码合并或变基到自己的分支才能解决这个文件上的潜在冲突。5.4 发起 PR 并完成 Code ReviewA 在托管平台上创建 Merge Request目标分支main源分支feature/user-login。PR 描述里写## 变更内容 - 新增 /login 接口支持用户名密码登录 - 新增 pytest 测试用例 ## 测试方法 - pytest test_app.py - 使用 curl 调用 /login 接口B、C、D 收到通知后在平台上查看文件改动逐行评论。比如 B 看到users字典中的密码明文评论“明文密码不适合生产环境建议使用哈希存储。本次可以先通过但需要记录一个后续问题。”A 根据评论修改代码这是一个非常常见的协作场景——有人提建议不一定立刻改可能先同意也可能说明原因。如果决定修改A 在本地分支继续改动# 文件路径app.py在 feature/user-login 分支上修改 # 这里只是演示实际生产环境应使用哈希存储 users { alice: hashed_password, bob: hashed_password, }重新提交推送git add app.py git commit -m fix: avoid storing plaintext password git pushPR 更新后B 看到新提交点同意。CI 通过后A 点击合并。合并策略选择 Squash and merge。5.5 配置分支保护规则分支保护是为了防止有人绕过评审流程直接推送到main。在托管平台设置中对main分支启用保护允许合入的条件至少 1 个 reviewer 批准。状态检查通过如果配置了 CI。禁止直接在main分支上 push。这一步的意义在于把“Code Review”从自觉行为变成强制流程。你可以口头约定大家都要评审但最好让平台强制执行。5.6 配置 CI 自动化检查在 GitHub 上可以使用 GitHub Actions在 GitLab 上可以使用 GitLab CI。以 GitLab CI 为例在项目根目录创建.gitlab-ci.yml# 文件路径.gitlab-ci.yml stages: - test test: stage: test image: python:3.11-slim before_script: - pip install -r requirements.txt script: - pytest -v这个配置会在每次 push 和 MR 时自动运行pytest测试失败则不能合并。如果使用 GitHub Actions创建.github/workflows/test.yml# 文件路径.github/workflows/test.yml name: test on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-pythonv5 with: python-version: 3.11 - run: pip install -r requirements.txt - run: pytest -v到这里一个最简单的“分支隔离 评审 自动测试”的协作闭环就搭好了。6. 运行结果与效果验证配置完成之后怎么判断这套流程真的生效了看几个指标就够了。6.1 本地验证功能A 在本地运行测试pytest -v预期输出类似test_health PASSED test_login_success PASSED test_login_fail PASSED这说明功能分支在合入前已经经过了自动化验证。6.2 验证 CI 状态在 MR 页面可以看到 pipeline 状态。如果没有配置 CI至少能在本地跑pytest如果配置了MR 页面会出现“测试通过/失败”的标记。合入前必须保证“通过”。6.3 验证分支保护策略尝试直接向main推送git checkout main git pull origin main # 尝试直接 push预期会收到类似remote: GitLab: You are not allowed to push code to protected branches on this project.的拒绝信息。这说明保护规则生效了团队成员只能通过 MR 合入。6.4 检查主干的提交历史一个功能合入后查看主线历史git log --oneline --graph如果使用了 Squash and merge历史会很干净类似* abc1234 (HEAD - main, origin/main) feat: add login API and tests (#2) * def5678 chore: init project每个功能对应一个提交方便回滚。如果需要回滚登录功能git revert 1244aabbcc然后推送到main即可在不重写历史的情况下撤销该功能。7. 常见问题与排查思路这套流程在落地过程中有几个非常典型的问题。问题现象可能原因排查方式解决方案推送分支时提示rejected远程分支有本地没有的提交执行git fetch和git log对比先 pull 或 rebase 再推送不要直接强推合并 MR 时提示冲突两个分支修改了同一处代码在本地合并目标分支定位冲突文件手动解决冲突后重新提交推送rebase 后推送被拒绝rebase 改写了已推送的提交检查远端分支状态如确定没有人使用该分支可强制推送否则改用 merge 同步CI 测试通过但本地失败本地依赖与 CI 环境不一致查看 CI 日志中的依赖版本将依赖版本锁定在 requirements 中PR 里出现无关文件的变更分支基于旧版本 main 创建或者提交时误加文件查看 PR 的文件变更列表用git rebase origin/main同步并清理误提交分支保护开启后无法推送新的 feature 分支推到远端也被保护检查分支保护规则中的“允许推送”范围只保护 main不需要保护 feature 分支不小心把功能分支合入了 main评审不严格或误点合并查看合并提交 hash使用git revert merge-commit并设置正确的合并分支参数7.1 冲突真的不可怕关键在于如何组织解决流程很多人一看到冲突就头皮发麻。实际上冲突是 Git 在告诉你两件事第一它无法自动判断该保留哪一方的改动第二你需要人工做一次“对话”。解决冲突的标准姿势是切换到自己的功能分支。把目标分支通常是main的最新代码合并或变基进来。在本地运行能复现冲突的测试。解决冲突后运行完整测试。提交推送。流程上我推荐在功能分支完成度较高、准备发起 MR 之前主动同步一次main而不是等 MR 创建后由平台提示冲突。这样可以减少互等时间。8. 最佳实践与工程建议前面已经讲完了操作流程这一节聊一些更“软”的建议。这些内容不能直接运行但能显著降低团队协作的摩擦成本。8.1 提交信息是一份文档不是流水账每次提交都在给项目写遗留文档。推荐约定式提交格式feat(scope): subject fix(scope): subject docs(scope): subject refactor(scope): subject test(scope): subject chore(scope): subject示例feat(auth): add login API fix(goods): reduce memory usage of goods list docs(readme): update deployment steps这样做的另一个作用是如果未来接入语义化版本发布工具如 semantic-release可以直接从提交信息生成 changelog。8.2 PR 越小越好但要有完整逻辑一个 PR 不要塞入多个无关功能。但也不要小到“改了一个空格”就发一个 PR。判断标准是这个 PR 能否被独立 Review、独立测试、独立回滚。如果能它就是合适的粒度。四人小组中产出一个 PR 的节奏通常是每天 1 到 2 个或者每半天 1 个。如果一个功能开发了两三天那么你更需要尽早把中间累积的代码通过小 PR 合并到主干而不是第三天才一次性合并。8.3 分支命名规范命名不是强迫症是为了让 CI 脚本和人员都能快速理解分支职责。推荐格式feature/新功能fix/缺陷修复docs/文档调整refactor/重构chore/构建或依赖调整例如feature/user-login fix/goods-price-type docs/api-usage这种命名和自动化工具的亲和度很高。比如 CI 可以判断只推送到feature/的分支。8.4 自动化检查要覆盖哪些内容至少应该包含编译/构建对于多模块项目尤其重要单元测试代码风格检查静态检查如 SonarQube 或 Python 中的 ruff、Java 中的 Checkstyle自动化检查的价值不在于数量而在于“稳定、快速、可信”。如果 CI 经常因为环境问题挂掉团队就会逐渐忽略 CI 状态反而让流程失效。8.5 让 Code Review 关注“变更目的”而不是“语法正确”很多人 Review 代码时只挑格式问题这不是最优做法。更有效的方式是审阅者先看 PR 描述理解它为什么存在。看测试是否覆盖核心场景。再逐行看实现。发现问题时给出建议和理由而不是简单说“这里不对”。四人的团队Review 的核心目的是“用四个人的视角发现一个人的盲区”而不是找一个代码风格警察。8.6 如何处理“紧急修复”和“功能开发”的冲突线上故障需要紧急修复。这时候不能等完整流程走完但也至少要做最小保障从main创建fix/urgent-xxx分支。修改并提交。推送后创建 MR。可以只请一个人快速 ReviewCI 照跑。合入后立刻回归验证。分支保护规则里通常有“允许跳过 review”的例外配置但建议不要开放给所有人。紧急修复也应该记录变更事后补评审。8.7 小团队不需要一上来就铺开复杂工具有些团队一听到协作规范就开始上项目管理、敏捷看板、自动部署、K8s。对四人团队来说先跑通“主干稳定、分支独立、评审合入”这三件事已经能解决 80% 的协作问题。工具链可以后面慢慢补齐但基础的分支纪律必须从一开始就建立。这也是很多团队最容易走偏的地方工具买了很多流程一样混乱最后变成了什么都在用什么都没落地。8.8 警惕“主干被污染”的几种情况项目开始一段时间后main分支可能被以下操作污染直接把机器生成的构建产物提交进main。本地修改过的配置文件被误合入。临时调试代码在合并前忘了移除。环境相关的.env文件被提交并推送到远端。针对这些情况最有效的不是事后清理而是提前把.gitignore写完整并在 CI 中加入“不允许包含敏感文件”的检查。尤其要强调任何密钥、密码、Token 都不要进 Git 仓库。如果真被提交了必须立刻作废相关密钥并重新生成而不是想着删掉文件重新提交因为历史里仍然存在。9. 总结让“我们四个真是太厉害了”成为必然结果回到开头的那个梗。一句“我们四个真是太厉害了”在团队协作语境下不应该只是事后的感叹而应该是一种可以复现的工程状态。它意味着四个人各自在独立分支上放心开发公共主干始终可用每次代码合入都有评审和自动化验证兜底出现冲突时大家知道该用什么命令、按什么顺序解决线上出问题时能快速定位到某个 MR、某次提交并且能安全回滚。这套能力的基础不是某个高深框架而是 Git 分支模型、Code Review 流程、自动化测试和分支保护规则的组合。它们不复杂但需要团队形成共识。读完这篇文章你可以先从最小改动开始实践新建一个纯测试仓库把main保护起来。两个人各自创建功能分支分别修改同一个文件。尝试用git rebase origin/main同步并解决冲突。走一次完整的 MR 合入流程。跑通这个最小闭环后再逐渐加入 CI、提交规范、自动化发布。你会发现“我们四个真是太厉害了”这句话会从一句玩笑话变成团队的日常。 
长河君 · 2026/9/7 6:53:58 · 阅读 1.2k 四人开发团队Git协作指南：分支模型、Code Review与持续集成实践
“我们四个真是太厉害了”——这句话最近在很多技术群里成了梗多半是几个人合作搞定了某个需求之后在群里互相吹捧时用的。但如果你真在一个开发小组里待过就会知道四个人一起写一个项目能让“团队士气高涨”的绝对不是上线那天的庆功而是从需求拆解到代码合并整个过程居然没出大乱子。一个人写代码难点在“写”四个人写代码难点就变成了“配合”。很多小团队明明人数不多却频繁遇到代码覆盖、冲突解不完、某人的改动悄悄破坏了另一个模块、上线前才发现分支合并错了等问题。这种混乱和人数没有必然关系和“协作方式”有直接关系。这篇文章要解决的就是这件事一个四人规模的小团队怎么用 Git 分支模型、Code Review、自动化检查和持续集成把日常开发从“薛定谔的合并”变成“可预期的流程”。不管你用的是 GitHub、GitLab 还是 Gitee核心方法都通用。1. 团队协作的真正痛点不是代码而是变更叠加先说一个很常见的场景。四个人同时开发一个 Web 项目分工大概是这样A 做用户登录B 做商品列表C 做订单接口D 做管理后台。每个人都觉得自己负责的模块很独立于是都在本地master或main分支上开发。上午还很正常下午问题就来了。A 改了一个工具类B 也在同一个文件里加了方法C 修改了数据库连接配置D 在本地也改了同一个配置。等大家往远程仓库推代码时Git 提示“无法快进推送”于是有人选择git pull结果冲突文件一个接一个。为了尽快解决问题有人直接把冲突全部改成“保留双方代码”结果项目编译都过不了。这种事经历几次之后团队就会形成一种默契谁也不敢动公共文件改之前先吼一声。但这种靠嗓门维持的协作规模稍微大一点就会失效。从根上讲问题出在三个方面没有清晰的分支策略。所有人都在一条主干上直接开发彼此的变更没有隔离。代码评审缺失。改动直接推到主干没有第二个人确认逻辑问题只能在运行时暴露。没有自动化验证关卡。合并之前没有编译、测试、静态检查冲突和低级错误只能靠人肉发现。所以要解决“四个人开发乱成一锅粥”的问题第一步不是写更多代码而是建立一套变更管理流程。1.1 “分支隔离 评审合并 自动检查”这套组合要解决什么用一句话概括让每一个人的改动先在自己的空间里完成经过验证和评审再回到主干。这套组合里各部分的职责很清晰环节解决什么问题通俗解释功能分支变更互相干扰每个人在独立分支上开发主干保持随时可发布的状态Code Review错误提前发现合入主干前至少另一个人看过改动自动检查低级错误拦截编译、测试、静态检查全自动跑不再靠自觉合并策略历史清晰、可回滚所有合入记录明确出了问题可以回退到固定节点这套流程本质上是在给“团队协作”建立缓冲区。你的代码先在分支上自证“能编译、测试通过、有人审过”才有资格进入主干。这不只是规范也是让“我们四个真是太厉害了”这句话多说几次的技术保障。2. 核心概念分支、提交、合并、远程协作的基础认知在配置流程之前先把几个容易混淆的概念理清楚。因为很多协作混乱其实是对 Git 对象和工作流理解不到位。2.1 分支不是文件夹是“可移动的指针”新手容易把分支理解成代码的“副本”其实 Git 分支本质上是一个指向提交的指针。创建分支非常轻量只是新建一个指针。当你在分支上提交时指针才会向前移动。理解这一点有什么用它决定了“切换分支”“合并分支”这些操作并不神秘也决定了你可以放心地多创建分支而不用怕占用太多空间。2.2 提交是“快照”不是“差异”Git 的提交不是保存当前版本和上一版本的差异而是保存当前所有文件的一个快照。为了节省空间Git 会复用没有变化的文件。这意味着每次提交都应该是一个逻辑完整的变更而不是“改一下再改一下”的碎碎念提交。提交信息写得清楚将来回滚、查问题会省很多力气。2.3 合并、变基、快进合并有什么区别合并merge会生成一个额外的合并提交保留两个分支的历史轨迹。变基rebase则是把你的提交“挪”到目标分支的最新提交后面历史像一条直线。两者没有绝对的谁更好看团队取舍操作历史形态优点缺点git merge有分叉、有合并节点保留真实开发过程回滚时能看出合并点历史复杂有大量 merge commitgit rebase线性历史看着干净方便git bisect定位问题改写了提交历史多人协作时若已推送需谨慎还有一个“快进合并”fast-forward。当你基于当前主干最新提交创建分支主干没有新的提交时合并分支可以直接把指针前移不生成合并提交。很多团队的 PR 合并不采用这种方式而是强制生成 merge commit就是为了保留一次合入记录。2.4 远程仓库不是“云盘”远程仓库remote更像是一个“约定的中间节点”所有人往这里推拉代码。origin只是默认的远程仓库名。常见的协作问题——比如rejected推送失败——本质上是因为远程分支上有你本地没有的提交Git 不允许强行覆盖除非你用了push -f但这很危险。理解了这些底层概念后面的流程设计就好理解了。3. 环境准备搭好 Git 与远程仓库的基础配置这里假设你用的是 Linux/macOS 或 Windows Git Bash。版本方面Git 2.x 都可以如果太老建议升级到 2.30 以上因为后续的一些分支命令更友好。本文演示的命令以通用 Git 命令为准不依赖特定托管平台。3.1 安装与基础配置git --version如果没安装参照对应系统安装即可。装完之后先设置身份信息因为每次提交都会记录这些信息git config --global user.name Your Name git config --global user.email yournameexample.com推荐设置默认分支名和提交时的默认编辑器git config --global init.defaultBranch main git config --global core.editor vim3.2 创建远程仓库并克隆到本地这里以常见的 Git 托管平台为例。假设你在平台上创建了一个空仓库地址是gitexample.com:team/four-dev.git那么克隆到本地git clone gitexample.com:team/four-dev.git cd four-dev如果你的仓库已经有文件需要在克隆前确认你本地是否清空了目标目录避免覆盖。3.3 设置 SSH 密钥以 GitHub/GitLab 通用方式为例为了避免每次推送都输入密码推荐配置 SSH key。先在本地生成ssh-keygen -t ed25519 -C yournameexample.com一路回车生成的公钥默认在~/.ssh/id_ed25519.pub。复制内容添加到 Git 托管平台的 SSH Keys 设置页面然后验证ssh -T gitexample.com看到欢迎信息说明连接成功。这一步不是必须的但能避免反复输入账号密码也让 CI 等自动化工具更容易接入。4. 核心流程拆解四人团队的分支与合并规范现在进入正题。我们把四人团队的分工定义成一组典型角色然后设计一套简单但完整的分支协作流程。这套流程不是教科书式的 Git Flow而是更适合小团队的轻量模型。4.1 分支模型设计主干分支main始终保持可发布状态。开发分支每个人从main检出自己的功能分支命名建议为feature/xxx、fix/xxx、docs/xxx等。例如main ├── feature/user-login (A 负责) ├── feature/goods-list (B 负责) ├── feature/order-api (C 负责) └── feature/admin-dashboard (D 负责)每完成一个小任务就可以向main发起合并请求。这里的关键判断是不要在 feature 分支之间互相合并。四个人不需要共享“开发分支”各干各的然后统一合回main。如果确实有公共代码需要先落地就让一个人先把它合到main其他人再拉取main的最新代码。4.2 一次完整的开发周期以 A 开发“用户登录”这个功能为例从最新main创建本地分支git checkout main git pull origin main git checkout -b feature/user-login开发和本地提交git add . git commit -m feat: add user login API提交信息建议遵循约定式提交风格feat、fix、docs、refactor等后面会讲。推送到远程git push -u origin feature/user-login在托管平台上发起 Pull Request / Merge Request目标分支选main标题写清楚改动意图描述里补充“为什么改”“怎么测试”。其他成员进行 Code ReviewCI 自动跑测试。Review 通过后点击合并。4.3 如何保持功能分支和 main 同步如果开发周期较长A 每天会拉一次main的最新代码到自己分支。两种做法这里推荐用 rebase 保持历史线性git checkout feature/user-login git fetch origin main git rebase origin/main如果遇到冲突Git 会停在冲突提交上。此时需要手动解决冲突然后git add . git rebase --continue这里有个重要提醒**rebase 改写提交历史所以只应对尚未被其他人共享的分支执行。**如果 A 已经把这个 feature 分支推到远程并且和 B 说“你帮我在这个分支上改一下”那就不适合 rebase应该改用 merge 或者先和团队确认好统一策略。之所以在同步main时更推荐 rebase是因为 feature 分支还没合入主干它的历史本来就可以整理合入后主干可以保持近似线性的历史定位问题更简单。4.4 合并到 main 的几种策略怎么选大多数托管平台在合并 PR 时提供选项策略效果适用场景Merge commit保留一次合并记录和全部历史分叉希望看到“合入动作”的团队Squash and merge把 PR 内多个提交压缩成一个希望主干历史整洁一个功能一个提交Rebase and merge把提交线性地接到目标分支想避免 merge commit同时保留每个提交对于四人小团队我个人建议在main分支上使用Squash and merge。因为它把整个功能分支压缩成一个提交主干非常干净。缺点是你丢失了 PR 内的中间提交细节但对小项目来说feat(user-login): ...这一个提交足够回滚和定位问题。5. 完整示例从空仓库到一次协作合并下面我们实际跑一遍流程。以 Python Flask 项目为例但重点不是 Flask而是协作流程。5.1 初始化项目在托管平台创建空仓库team-four-demo然后本地初始化mkdir team-four-demo cd team-four-demo git init git checkout -b main创建.gitignore避免把虚拟环境、缓存等文件提交进去。# 文件路径.gitignore __pycache__/ *.py[cod] .venv/ venv/ .env .idea/ .vscode/ *.log创建 README# team-four-demo 四人协作示例项目创建初始requirements.txtflask3.0.0 pytest7.4.0创建最小应用# 文件路径app.py from flask import Flask app Flask(__name__) app.route(/health) def health(): return {status: ok}提交并推送到远程git add . git commit -m chore: init project git remote add origin gitexample.com:team/team-four-demo.git git push -u origin main5.2 A 添加登录接口A 在本地创建功能分支git checkout main git pull origin main git checkout -b feature/user-login在app.py中添加登录接口# 文件路径app.py from flask import Flask, request, jsonify app Flask(__name__) users { alice: 123456, bob: 654321, } app.route(/health) def health(): return {status: ok} app.route(/login, methods[POST]) def login(): data request.get_json() username data.get(username) password data.get(password) if users.get(username) password: return jsonify({code: 0, message: success}) return jsonify({code: 1001, message: invalid username or password}), 401同时添加测试文件# 文件路径test_app.py import json import pytest from app import app pytest.fixture def client(): app.config[TESTING] True with app.test_client() as client: yield client def test_health(client): resp client.get(/health) assert resp.status_code 200 assert resp.get_json() {status: ok} def test_login_success(client): resp client.post( /login, datajson.dumps({username: alice, password: 123456}), content_typeapplication/json, ) assert resp.status_code 200 assert resp.get_json()[code] 0 def test_login_fail(client): resp client.post( /login, datajson.dumps({username: alice, password: wrong}), content_typeapplication/json, ) assert resp.status_code 401 assert resp.get_json()[code] 1001提交git add app.py test_app.py git commit -m feat: add login API and tests git push -u origin feature/user-login5.3 B 创建商品列表接口B 的操作路径完全一样git checkout main git pull origin main git checkout -b feature/goods-list在app.py中添加商品列表GOODS [ {id: 1, name: apple, price: 5.0}, {id: 2, name: banana, price: 3.5}, ] app.route(/goods, methods[GET]) def goods_list(): return jsonify({code: 0, data: GOODS})提交并推送git add app.py git commit -m feat: add goods list API git push -u origin feature/goods-list这里可以看到A 和 B 都修改了app.py但由于处在不同分支互不干扰。等 A 的 PR 先合入mainB 就需要把main的最新代码合并或变基到自己的分支才能解决这个文件上的潜在冲突。5.4 发起 PR 并完成 Code ReviewA 在托管平台上创建 Merge Request目标分支main源分支feature/user-login。PR 描述里写## 变更内容 - 新增 /login 接口支持用户名密码登录 - 新增 pytest 测试用例 ## 测试方法 - pytest test_app.py - 使用 curl 调用 /login 接口B、C、D 收到通知后在平台上查看文件改动逐行评论。比如 B 看到users字典中的密码明文评论“明文密码不适合生产环境建议使用哈希存储。本次可以先通过但需要记录一个后续问题。”A 根据评论修改代码这是一个非常常见的协作场景——有人提建议不一定立刻改可能先同意也可能说明原因。如果决定修改A 在本地分支继续改动# 文件路径app.py在 feature/user-login 分支上修改 # 这里只是演示实际生产环境应使用哈希存储 users { alice: hashed_password, bob: hashed_password, }重新提交推送git add app.py git commit -m fix: avoid storing plaintext password git pushPR 更新后B 看到新提交点同意。CI 通过后A 点击合并。合并策略选择 Squash and merge。5.5 配置分支保护规则分支保护是为了防止有人绕过评审流程直接推送到main。在托管平台设置中对main分支启用保护允许合入的条件至少 1 个 reviewer 批准。状态检查通过如果配置了 CI。禁止直接在main分支上 push。这一步的意义在于把“Code Review”从自觉行为变成强制流程。你可以口头约定大家都要评审但最好让平台强制执行。5.6 配置 CI 自动化检查在 GitHub 上可以使用 GitHub Actions在 GitLab 上可以使用 GitLab CI。以 GitLab CI 为例在项目根目录创建.gitlab-ci.yml# 文件路径.gitlab-ci.yml stages: - test test: stage: test image: python:3.11-slim before_script: - pip install -r requirements.txt script: - pytest -v这个配置会在每次 push 和 MR 时自动运行pytest测试失败则不能合并。如果使用 GitHub Actions创建.github/workflows/test.yml# 文件路径.github/workflows/test.yml name: test on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-pythonv5 with: python-version: 3.11 - run: pip install -r requirements.txt - run: pytest -v到这里一个最简单的“分支隔离 评审 自动测试”的协作闭环就搭好了。6. 运行结果与效果验证配置完成之后怎么判断这套流程真的生效了看几个指标就够了。6.1 本地验证功能A 在本地运行测试pytest -v预期输出类似test_health PASSED test_login_success PASSED test_login_fail PASSED这说明功能分支在合入前已经经过了自动化验证。6.2 验证 CI 状态在 MR 页面可以看到 pipeline 状态。如果没有配置 CI至少能在本地跑pytest如果配置了MR 页面会出现“测试通过/失败”的标记。合入前必须保证“通过”。6.3 验证分支保护策略尝试直接向main推送git checkout main git pull origin main # 尝试直接 push预期会收到类似remote: GitLab: You are not allowed to push code to protected branches on this project.的拒绝信息。这说明保护规则生效了团队成员只能通过 MR 合入。6.4 检查主干的提交历史一个功能合入后查看主线历史git log --oneline --graph如果使用了 Squash and merge历史会很干净类似* abc1234 (HEAD - main, origin/main) feat: add login API and tests (#2) * def5678 chore: init project每个功能对应一个提交方便回滚。如果需要回滚登录功能git revert 1244aabbcc然后推送到main即可在不重写历史的情况下撤销该功能。7. 常见问题与排查思路这套流程在落地过程中有几个非常典型的问题。问题现象可能原因排查方式解决方案推送分支时提示rejected远程分支有本地没有的提交执行git fetch和git log对比先 pull 或 rebase 再推送不要直接强推合并 MR 时提示冲突两个分支修改了同一处代码在本地合并目标分支定位冲突文件手动解决冲突后重新提交推送rebase 后推送被拒绝rebase 改写了已推送的提交检查远端分支状态如确定没有人使用该分支可强制推送否则改用 merge 同步CI 测试通过但本地失败本地依赖与 CI 环境不一致查看 CI 日志中的依赖版本将依赖版本锁定在 requirements 中PR 里出现无关文件的变更分支基于旧版本 main 创建或者提交时误加文件查看 PR 的文件变更列表用git rebase origin/main同步并清理误提交分支保护开启后无法推送新的 feature 分支推到远端也被保护检查分支保护规则中的“允许推送”范围只保护 main不需要保护 feature 分支不小心把功能分支合入了 main评审不严格或误点合并查看合并提交 hash使用git revert merge-commit并设置正确的合并分支参数7.1 冲突真的不可怕关键在于如何组织解决流程很多人一看到冲突就头皮发麻。实际上冲突是 Git 在告诉你两件事第一它无法自动判断该保留哪一方的改动第二你需要人工做一次“对话”。解决冲突的标准姿势是切换到自己的功能分支。把目标分支通常是main的最新代码合并或变基进来。在本地运行能复现冲突的测试。解决冲突后运行完整测试。提交推送。流程上我推荐在功能分支完成度较高、准备发起 MR 之前主动同步一次main而不是等 MR 创建后由平台提示冲突。这样可以减少互等时间。8. 最佳实践与工程建议前面已经讲完了操作流程这一节聊一些更“软”的建议。这些内容不能直接运行但能显著降低团队协作的摩擦成本。8.1 提交信息是一份文档不是流水账每次提交都在给项目写遗留文档。推荐约定式提交格式feat(scope): subject fix(scope): subject docs(scope): subject refactor(scope): subject test(scope): subject chore(scope): subject示例feat(auth): add login API fix(goods): reduce memory usage of goods list docs(readme): update deployment steps这样做的另一个作用是如果未来接入语义化版本发布工具如 semantic-release可以直接从提交信息生成 changelog。8.2 PR 越小越好但要有完整逻辑一个 PR 不要塞入多个无关功能。但也不要小到“改了一个空格”就发一个 PR。判断标准是这个 PR 能否被独立 Review、独立测试、独立回滚。如果能它就是合适的粒度。四人小组中产出一个 PR 的节奏通常是每天 1 到 2 个或者每半天 1 个。如果一个功能开发了两三天那么你更需要尽早把中间累积的代码通过小 PR 合并到主干而不是第三天才一次性合并。8.3 分支命名规范命名不是强迫症是为了让 CI 脚本和人员都能快速理解分支职责。推荐格式feature/新功能fix/缺陷修复docs/文档调整refactor/重构chore/构建或依赖调整例如feature/user-login fix/goods-price-type docs/api-usage这种命名和自动化工具的亲和度很高。比如 CI 可以判断只推送到feature/的分支。8.4 自动化检查要覆盖哪些内容至少应该包含编译/构建对于多模块项目尤其重要单元测试代码风格检查静态检查如 SonarQube 或 Python 中的 ruff、Java 中的 Checkstyle自动化检查的价值不在于数量而在于“稳定、快速、可信”。如果 CI 经常因为环境问题挂掉团队就会逐渐忽略 CI 状态反而让流程失效。8.5 让 Code Review 关注“变更目的”而不是“语法正确”很多人 Review 代码时只挑格式问题这不是最优做法。更有效的方式是审阅者先看 PR 描述理解它为什么存在。看测试是否覆盖核心场景。再逐行看实现。发现问题时给出建议和理由而不是简单说“这里不对”。四人的团队Review 的核心目的是“用四个人的视角发现一个人的盲区”而不是找一个代码风格警察。8.6 如何处理“紧急修复”和“功能开发”的冲突线上故障需要紧急修复。这时候不能等完整流程走完但也至少要做最小保障从main创建fix/urgent-xxx分支。修改并提交。推送后创建 MR。可以只请一个人快速 ReviewCI 照跑。合入后立刻回归验证。分支保护规则里通常有“允许跳过 review”的例外配置但建议不要开放给所有人。紧急修复也应该记录变更事后补评审。8.7 小团队不需要一上来就铺开复杂工具有些团队一听到协作规范就开始上项目管理、敏捷看板、自动部署、K8s。对四人团队来说先跑通“主干稳定、分支独立、评审合入”这三件事已经能解决 80% 的协作问题。工具链可以后面慢慢补齐但基础的分支纪律必须从一开始就建立。这也是很多团队最容易走偏的地方工具买了很多流程一样混乱最后变成了什么都在用什么都没落地。8.8 警惕“主干被污染”的几种情况项目开始一段时间后main分支可能被以下操作污染直接把机器生成的构建产物提交进main。本地修改过的配置文件被误合入。临时调试代码在合并前忘了移除。环境相关的.env文件被提交并推送到远端。针对这些情况最有效的不是事后清理而是提前把.gitignore写完整并在 CI 中加入“不允许包含敏感文件”的检查。尤其要强调任何密钥、密码、Token 都不要进 Git 仓库。如果真被提交了必须立刻作废相关密钥并重新生成而不是想着删掉文件重新提交因为历史里仍然存在。9. 总结让“我们四个真是太厉害了”成为必然结果回到开头的那个梗。一句“我们四个真是太厉害了”在团队协作语境下不应该只是事后的感叹而应该是一种可以复现的工程状态。它意味着四个人各自在独立分支上放心开发公共主干始终可用每次代码合入都有评审和自动化验证兜底出现冲突时大家知道该用什么命令、按什么顺序解决线上出问题时能快速定位到某个 MR、某次提交并且能安全回滚。这套能力的基础不是某个高深框架而是 Git 分支模型、Code Review 流程、自动化测试和分支保护规则的组合。它们不复杂但需要团队形成共识。读完这篇文章你可以先从最小改动开始实践新建一个纯测试仓库把main保护起来。两个人各自创建功能分支分别修改同一个文件。尝试用git rebase origin/main同步并解决冲突。走一次完整的 MR 合入流程。跑通这个最小闭环后再逐渐加入 CI、提交规范、自动化发布。你会发现“我们四个真是太厉害了”这句话会从一句玩笑话变成团队的日常。