GitHub/Gitee 团队协作完整流程笔记

本文完整梳理 GitHub / Gitee 平台下，仓库管理员与普通开发者的标准化协作全流程，从仓库初始化、权限配置、分支规范，到 Pull Request（PR）提交流程、审核合并、代码同步、冲突处理全覆盖，特别标注「管理员直推」与「开发者提交」的权限差异细节，适合作为团队协作规范参考，也适合新手入门查漏补缺。

名词统一：GitHub 叫 Pull Request（PR），Gitee 叫「合并请求（MR）」，逻辑完全一致，下文统一简称 PR。

一、前置准备：仓库初始化与权限规则（管理员操作）

所有协作规则的底层逻辑，都由这一步的权限和分支保护决定。

1.1 仓库与基础分支初始化

管理员新建远程仓库后，先搭建基础分支骨架：

1. 初始化主分支main（或master）：作为生产环境稳定分支，存放可上线的最终代码
2. 创建开发主干分支develop：日常开发的基准分支，所有功能最终合入这里
3. 后续所有功能开发都基于develop拉出子分支，禁止直接在主分支写代码

1.2 角色权限划分（核心规则）

不同角色的权限差异，直接决定了「谁能直接改代码、谁必须走审核」。

1.3 分支保护规则（强制审核的核心配置）

管理员在仓库设置中开启main/develop分支保护，是实现「开发者提交必须审核」的关键开关，通常配置以下规则：

1. 禁止普通开发者直接推送代码到受保护分支
2. 所有合入受保护分支的代码，必须通过 PR 方式提交
3. PR 必须经过指定审核人（管理员）审批通过，才可执行合并
4. 可附加规则：CI 自动化检查通过、无代码冲突、多人审核通过才能合并
5. 可选：合并后自动删除源功能分支，保持仓库整洁

✅核心协作原理（必须理解）

• 管理员拥有受保护分支的豁免推送权，更新后直接写入远程主分支
• 普通开发者无受保护分支推送权限，所有改动必须走「功能分支 + PR 审核」通道
• 只有管理员合并 PR 后，代码才会正式进入主分支，其他开发者刷新拉取才能看到更新

二、标准分支协作规范（精简 Git-Flow）

团队统一分支命名和用途，从根源减少混乱和冲突。

1. main：生产稳定分支，仅存放可上线的代码，不直接开发
2. develop：开发主干分支，存放已审核通过的迭代功能代码
3. feature/xxx：功能开发分支，开发者每人一条，基于 develop 创建
   • 示例：feature/user-login、feature/order-list
4. hotfix/xxx：线上紧急bug修复分支，基于 main 创建
5. release/vx.x.x：版本发布预备分支，用于上线前测试

三、开发者完整提交流程（从开发到提PR）

普通开发者的标准作业流程，全程不直接触碰主分支。

步骤1：同步远程最新代码

每次开新需求前必做，最大限度避免后续冲突。

# 切换到开发主干gitcheckout develop# 拉取远程最新代码（管理员更新的内容，这里直接就能拉到）gitpull origin develop

💡 笔记标注：管理员在远程更新了 develop/main 后，所有开发者执行git pull就能直接同步，不需要任何审核，这就是「管理员更新，其他人直接获取」的场景。

步骤2：新建专属功能分支

基于最新的 develop 分支，创建自己的功能分支，全程在这个分支写代码。

# 新建并切换到功能分支gitcheckout-bfeature/user-login

步骤3：本地开发与提交

功能开发过程中，可以拆分成多次小提交，保持提交记录清晰。

# 查看改动文件gitstatus# 添加文件到暂存区gitadd.# 提交到本地仓库，备注遵循规范：feat/fix/docs + 描述gitcommit-m"feat: 新增登录页面表单校验逻辑"

步骤4：推送功能分支到远程仓库

功能分支不受保护规则限制，开发者可以自由推送。

gitpush origin feature/user-login

⚠️ 关键细节：推送完成后，代码只存在于你自己的功能分支里，develop主分支完全没有变化，其他开发者拉取代码也看不到你写的功能。

步骤5：网页端发起 PR（合并请求）

1. 进入仓库网页，会自动弹出「创建合并请求」的提示
2. 填写 PR 核心信息：
   • 目标分支（base）：选择develop（要合入的主干分支）
   • 源分支（compare）：选择你刚推送的feature/user-login
   • PR 标题：简洁说明本次功能/修复内容
   • 详细描述：改动点、测试方法、关联需求/工单、截图附件
   • 指定审核人：仓库管理员
3. 点击创建，正式提交审核

✅ 提交 PR 后的状态：
远程 develop 分支仍然不会更新；只有管理员审核通过并执行合并后，代码才会流入主分支，全团队刷新拉取才能看到。

四、管理员 PR 审核全流程

管理员收到 PR 通知后，进入审核页面完成全流程校验。

4.1 审核标准步骤

1. 基础信息校验：检查分支是否正确、提交记录是否规范、有没有修改无关文件
2. 代码逐行审查：查看新增/删除的代码，检查逻辑、规范、安全隐患、冗余代码
3. 自动化检查：确认 CI 流水线（单元测试、代码格式、构建）是否通过
4. 给出审核结论

4.2 四种审核操作

1. 批准（Approve）：代码合格，同意合并
2. 请求修改（Request changes）：存在问题，打回开发者修改，修改完成后重新审核
3. 评论（Comment）：仅提出疑问/建议，不做通过或拒绝的判定
4. 关闭 PR：直接废弃本次合并请求，对应功能分支可删除

4.3 审核通过：执行合并

PR 批准后，管理员选择合并方式，完成代码合入。常见三种合并模式：

1. 创建合并提交（Merge Commit）：完整保留功能分支所有提交记录，生成一条合并节点，历史可追溯，大型项目常用
2. 挤压合并（Squash and Merge）：把功能分支多次提交压缩成 1 条提交，主分支日志干净整洁，适合小功能
3. 变基合并（Rebase and Merge）：把功能分支提交平移到主干顶端，提交线呈直线无分叉，历史线性美观

4.4 合并后的自动效果

1. 代码正式合入远程develop受保护分支
2. 全团队所有开发者执行git pull后，就能同步到本次审核通过的代码
3. 若开启自动删除分支，远程的功能分支会被自动清理

五、合并后：开发者同步最新代码

PR 合并后，开发者同步主干代码，清理本地废弃分支。

# 切换到开发主干gitcheckout develop# 拉取最新代码，获取已审核通过的功能gitpull origin develop# 删除本地已完成的功能分支gitbranch-dfeature/user-login

六、高频问题：代码冲突处理流程

冲突产生原因

多个开发者同时修改了同一个文件的同一行代码，远程主干已经合入了别人的代码，你的 PR 就会提示冲突，无法合并。

标准解决方式（本地处理，推荐）

1. 先拉取最新的主干代码

gitcheckout developgitpull origin develop

2. 切回自己的功能分支，执行变基

gitcheckout feature/xxxgitrebase develop

3. 打开冲突文件，手动编辑保留最终代码，删除冲突标记
4. 解决完成后继续变基

gitadd.gitrebase--continue

5. 强制推送到远程功能分支，PR 会自动更新

gitpush-forigin feature/xxx

💡 踩坑提醒：只有自己的功能分支可以强制推送，绝对不要对 main/develop 公共主干执行强制推送，会导致团队代码错乱。

七、特殊场景：管理员直接更新主分支

这是和「开发者提交PR」完全不同的流程，也是很多新手容易混淆的点。

7.1 操作流程

1. 管理员本地切换到develop/main分支，直接修改代码
2. 本地提交后，直接推送到远程

gitpush origin develop

3. 推送直接生效，不需要走 PR 审核流程

7.2 权限差异对比表

八、容易忽略的协作细节

1. PR 提交后、未合并前，开发者可以继续往功能分支推送代码，PR 会自动同步更新，不用重复新建
2. 支持多人审核，可配置「必须 N 个审核人通过才能合并」，适合大型团队
3. PR 页面支持行内评论，开发者和审核人可以针对某一行代码讨论修改
4. 分支保护可以额外配置「禁止强制推送」「禁止删除主分支」，避免误操作
5. 多人协作不要共用同一条功能分支，一人一条 feature 分支，从根源减少冲突
6. 线上回滚公共分支用git revert（生成反向提交，不删历史），不要用git reset，避免团队代码不同步

九、一句话总结全流程

管理员建好仓库锁死主分支 → 所有人拉取最新代码 → 开发者各自建分支写代码 → 推送分支提PR → 管理员审核合并进主干 → 全员拉取同步更新；管理员自己改主干可以直接推，开发者改主干必须走审核。