团队 Git 标准化开发流程规范
一、 核心原则 (Team Rules)
在进入具体命令之前，所有成员必须达成共识的"三大铁律"：
- 禁止直接推送到主分支 ：
master(或main) 分支是受保护的，永远不要直接git push上去。 - 一切皆分支 ：开发新功能、修复 Bug，必须从主分支切出新的
feature分支。 - 提交必审查 ：所有代码合并必须通过 Pull Request (PR) 进行，严禁私下合并。
二、 标准开发工作流 (Standard Workflow)
这是每位开发人员每天重复的标准步骤，请按此流程操作：
1. 同步代码 (保持最新)
在开始工作前，确保你的本地主分支是最新的。
bash
git checkout master
git pull origin master2. 创建功能分支 (Start Feature)
基于最新的主分支，创建属于你的功能分支。
- 命名规范 ：
feat/功能简述或fix/问题简述
bash
git checkout -b feat/user-login3. 开发与提交 (Code & Commit)
开发完成后，将文件添加到暂存区并提交。
- 提交规范 ：格式必须为
<类型>(<范围>): <简短描述>feat: 新功能fix: 修补 Bugdocs: 修改文档style: 代码格式调整（不影响代码运行）refactor: 重构（即不是新增功能，也不是修改 bug 的代码变动）chore: 构建过程或辅助工具的变动
bash
git add .
git commit -m "feat(auth): 实现用户登录接口"4. 推送分支 (Push)
将本地分支推送到远程仓库（Gitee/GitHub）。
bash
git push -u origin feat/user-login5. 发起合并请求 (Pull Request)
- 前往代码托管平台网页。
- 点击"新建 Pull Request"。
- 源分支 ：
feat/user-login-> 目标分支 ：master。 - 指派同事进行代码审查 (Code Review)。
6. 合并与清理 (Merge & Clean)
- PR 审核通过后，在网页上点击"合并"。
- 删除已合并的远程分支。
- 本地删除旧分支，切换回主分支：
bash
git checkout master
git branch -d feat/user-login三、 分支管理策略 (Branch Strategy)
为了保持仓库整洁，我们采用以下分支模型：
| 分支类型 | 命名示例 | 说明 | 存活周期 |
|---|---|---|---|
| 主分支 | master / main |
生产环境代码。随时可发布，严禁直接 Push。 | 永久 |
| 功能分支 | feat/login |
日常开发。从 master 切出，开发完合并回 master。 | 短期 |
| 修复分支 | fix/order-bug |
紧急修复。从 master 切出，修复后合并回 master。 | 短期 |
| 发布分支 | release/v1.0 |
预发布。用于测试和微调，不开发新功能。 | 短期 |
四、 常见场景与应急处理 (Scenarios & Fixes)
开发过程中难免遇到意外，请按照标准方式处理，不要暴力操作。
场景 1：代码冲突 (Conflict)
当多人修改了同一个文件的同一行代码时发生。
- 处理流程 ：
git pull origin master(拉取最新代码触发冲突)。- 打开冲突文件，手动编辑保留需要的代码（删除
<<<<<<<等标记）。 git add .(标记冲突已解决)。git commit -m "解决合并冲突"。
场景 2：撤销修改 (Undo)
- 撤销工作区修改 （文件还没 add）：
git checkout -- <文件名>(丢弃本地修改，恢复到最后一次 commit 的状态)。 - 撤销暂存区修改 （文件已经 add 了，想改）：
git reset HEAD <文件名>。 - 撤销刚才的 Commit （还没 push）：
git reset --soft HEAD^(保留代码，撤销提交动作)。
场景 3：代码写错了，已经 Push 了
千万不要删除历史记录（除非你确定没人拉取），而是应该使用 revert。
- 命令 ：
git revert <错误的提交ID> - 作用：生成一个新的提交，内容正好与错误的提交相反，以此抵消错误，同时保留历史记录。
场景 4：临时切换分支
代码写了一半，突然要修个紧急 Bug，不想提交半成品。
- 命令 ：
git stash(暂存现场) - 恢复 ：修完 Bug 回来后执行
git stash pop。
五、 为什么我们需要 Pull Request？
- 代码质量把控：PR 是代码合入前的最后一道防线，通过同事的审查（Code Review）发现潜在 Bug。
- 知识共享：团队成员可以通过阅读 PR 了解其他人写了什么代码，避免"代码孤岛"。
- 持续集成：PR 可以触发自动化测试，确保新代码不会搞挂旧功能。
- 可追溯性：每一次合并都有据可查，知道是谁、在什么时候、为什么合并了这段代码。
给团队的建议：
"Git 只是一个工具，规范才是核心。请大家严格遵守分支命名和提交信息规范，这会让我们的协作效率提升一倍。"
进阶操作：Cherry-Pick (精准移植，但慎用)
⚠️ 注意：此命令属于"外科手术式"操作，严禁在常规功能开发中使用，仅用于以下特定场景。
1. 什么是 Cherry-Pick？
普通的 merge 是把整个分支的代码合并过来，而 cherry-pick 是只选取某一个特定的提交（Commit），将其应用到当前分支。
2. 什么时候必须用它？
紧急修复 (Hotfix)：
- 场景：开发分支 (dev) 上刚刚修复了一个紧急 Bug，但 dev 分支上还有很多没测完的新功能。
- 操作：不能合并整个 dev 分支到 master，只能用 cherry-pick 把那个修复 Bug 的提交单独"摘"到 master 上。
跨分支复用代码：
- 场景：同事在 A 分支写了一个通用的工具类方法，你在 B 分支开发，急需这个方法，但你不想要 A 分支的其他业务代码。
- 操作：找到同事提交工具类的那个 Commit ID，cherry-pick 到你的分支。
3. 操作命令
bash
# 1. 切换到目标分支 (你想把代码放哪去)
git checkout master
# 2. 执行摘取 (后面跟提交的哈希值)
git cherry-pick <commit-hash>
# 3. 如果有冲突，解决冲突后执行：
git cherry-pick --continue4. 警告
- 不要滥用：如果你只是想同步代码，请用 merge 或 rebase。
- 避免重复：如果你 cherry-pick 了一个提交，后续又 merge 了包含该提交的分支，Git 可能会报错或产生重复代码。
- 哈希值变更：cherry-pick 后，新生成的提交哈希值会改变，但代码内容不变。