GitHub/Gitee 团队协作笔记

GitHub/Gitee 团队协作完整流程笔记本文完整梳理 GitHub / Gitee 平台下仓库管理员与普通开发者的标准化协作全流程从仓库初始化、权限配置、分支规范到 Pull RequestPR提交流程、审核合并、代码同步、冲突处理全覆盖特别标注「管理员直推」与「开发者提交」的权限差异细节适合作为团队协作规范参考也适合新手入门查漏补缺。名词统一GitHub 叫 Pull RequestPRGitee 叫「合并请求MR」逻辑完全一致下文统一简称 PR。一、前置准备仓库初始化与权限规则管理员操作所有协作规则的底层逻辑都由这一步的权限和分支保护决定。1.1 仓库与基础分支初始化管理员新建远程仓库后先搭建基础分支骨架初始化主分支main或master作为生产环境稳定分支存放可上线的最终代码创建开发主干分支develop日常开发的基准分支所有功能最终合入这里后续所有功能开发都基于develop拉出子分支禁止直接在主分支写代码1.2 角色权限划分核心规则不同角色的权限差异直接决定了「谁能直接改代码、谁必须走审核」。角色权限范围核心行为限制管理员Owner/管理者仓库全部权限可直接推送主分支、审核PR、合并分支、管理成员、配置规则普通开发者提交者推送普通分支、提交PR默认无法直接推送 main/develop 等受保护分支只能新建功能分支提交PR等待管理员审核1.3 分支保护规则强制审核的核心配置管理员在仓库设置中开启main/develop分支保护是实现「开发者提交必须审核」的关键开关通常配置以下规则禁止普通开发者直接推送代码到受保护分支所有合入受保护分支的代码必须通过 PR 方式提交PR 必须经过指定审核人管理员审批通过才可执行合并可附加规则CI 自动化检查通过、无代码冲突、多人审核通过才能合并可选合并后自动删除源功能分支保持仓库整洁✅核心协作原理必须理解管理员拥有受保护分支的豁免推送权更新后直接写入远程主分支普通开发者无受保护分支推送权限所有改动必须走「功能分支 PR 审核」通道只有管理员合并 PR 后代码才会正式进入主分支其他开发者刷新拉取才能看到更新二、标准分支协作规范精简 Git-Flow团队统一分支命名和用途从根源减少混乱和冲突。main生产稳定分支仅存放可上线的代码不直接开发develop开发主干分支存放已审核通过的迭代功能代码feature/xxx功能开发分支开发者每人一条基于 develop 创建示例feature/user-login、feature/order-listhotfix/xxx线上紧急bug修复分支基于 main 创建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-mfeat: 新增登录页面表单校验逻辑步骤4推送功能分支到远程仓库功能分支不受保护规则限制开发者可以自由推送。gitpush origin feature/user-login⚠️ 关键细节推送完成后代码只存在于你自己的功能分支里develop主分支完全没有变化其他开发者拉取代码也看不到你写的功能。步骤5网页端发起 PR合并请求进入仓库网页会自动弹出「创建合并请求」的提示填写 PR 核心信息目标分支base选择develop要合入的主干分支源分支compare选择你刚推送的feature/user-loginPR 标题简洁说明本次功能/修复内容详细描述改动点、测试方法、关联需求/工单、截图附件指定审核人仓库管理员点击创建正式提交审核✅ 提交 PR 后的状态远程 develop 分支仍然不会更新只有管理员审核通过并执行合并后代码才会流入主分支全团队刷新拉取才能看到。四、管理员 PR 审核全流程管理员收到 PR 通知后进入审核页面完成全流程校验。4.1 审核标准步骤基础信息校验检查分支是否正确、提交记录是否规范、有没有修改无关文件代码逐行审查查看新增/删除的代码检查逻辑、规范、安全隐患、冗余代码自动化检查确认 CI 流水线单元测试、代码格式、构建是否通过给出审核结论4.2 四种审核操作批准Approve代码合格同意合并请求修改Request changes存在问题打回开发者修改修改完成后重新审核评论Comment仅提出疑问/建议不做通过或拒绝的判定关闭 PR直接废弃本次合并请求对应功能分支可删除4.3 审核通过执行合并PR 批准后管理员选择合并方式完成代码合入。常见三种合并模式创建合并提交Merge Commit完整保留功能分支所有提交记录生成一条合并节点历史可追溯大型项目常用挤压合并Squash and Merge把功能分支多次提交压缩成 1 条提交主分支日志干净整洁适合小功能变基合并Rebase and Merge把功能分支提交平移到主干顶端提交线呈直线无分叉历史线性美观4.4 合并后的自动效果代码正式合入远程develop受保护分支全团队所有开发者执行git pull后就能同步到本次审核通过的代码若开启自动删除分支远程的功能分支会被自动清理五、合并后开发者同步最新代码PR 合并后开发者同步主干代码清理本地废弃分支。# 切换到开发主干gitcheckout develop# 拉取最新代码获取已审核通过的功能gitpull origin develop# 删除本地已完成的功能分支gitbranch-dfeature/user-login六、高频问题代码冲突处理流程冲突产生原因多个开发者同时修改了同一个文件的同一行代码远程主干已经合入了别人的代码你的 PR 就会提示冲突无法合并。标准解决方式本地处理推荐先拉取最新的主干代码gitcheckout developgitpull origin develop切回自己的功能分支执行变基gitcheckout feature/xxxgitrebase develop打开冲突文件手动编辑保留最终代码删除冲突标记解决完成后继续变基gitadd.gitrebase--continue强制推送到远程功能分支PR 会自动更新gitpush-forigin feature/xxx 踩坑提醒只有自己的功能分支可以强制推送绝对不要对 main/develop 公共主干执行强制推送会导致团队代码错乱。七、特殊场景管理员直接更新主分支这是和「开发者提交PR」完全不同的流程也是很多新手容易混淆的点。7.1 操作流程管理员本地切换到develop/main分支直接修改代码本地提交后直接推送到远程gitpush origin develop推送直接生效不需要走 PR 审核流程7.2 权限差异对比表操作主体操作方式是否需要审核其他开发者何时可见管理员直接推送主分支不需要推送完成后执行git pull立即可见普通开发者功能分支 提交 PR必须管理员审核合并PR 被管理员合并后执行git pull可见八、容易忽略的协作细节PR 提交后、未合并前开发者可以继续往功能分支推送代码PR 会自动同步更新不用重复新建支持多人审核可配置「必须 N 个审核人通过才能合并」适合大型团队PR 页面支持行内评论开发者和审核人可以针对某一行代码讨论修改分支保护可以额外配置「禁止强制推送」「禁止删除主分支」避免误操作多人协作不要共用同一条功能分支一人一条 feature 分支从根源减少冲突线上回滚公共分支用git revert生成反向提交不删历史不要用git reset避免团队代码不同步九、一句话总结全流程管理员建好仓库锁死主分支 → 所有人拉取最新代码 → 开发者各自建分支写代码 → 推送分支提PR → 管理员审核合并进主干 → 全员拉取同步更新管理员自己改主干可以直接推开发者改主干必须走审核。