Git 团队开发全流程指南
在实际工程开发中，很多 Git 问题并不是因为不会写代码，而是分支管理策略出了问题。比如直接在 origin/xxx 上开发、不理解为什么进入 detached HEAD 状态、提交后感觉代码'丢了'，或者对 git pull、fetch、merge 的概念混淆。
下面这套流程是真实公司通用的标准做法，从 git clone 开始，涵盖创建本地分支、开发、同步、提交到合并，每一步都尽量规避常见坑点。
一、初始化环境（只需一次）
在开始之前，确保你的 Git 配置正确，这样提交的记录才会带上正确的作者信息。
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
验证配置是否生效：
git config --global -l
二、克隆仓库与理解结构
很多人以为 git clone 只是把代码拷下来，其实它自动完成了四件事：创建一个本地仓库、添加远端仓库（默认名为 origin）、执行一次 fetch、生成远端跟踪分支。
git clone <repo_url>
cd <repo_dir>
你可以用以下命令验证当前状态：
git status
git branch
git branch -a
通常会看到类似这样的输出：
* main
remotes/origin/main
remotes/origin/feature/driver
这里的关键在于：你看到的是远端快照（如 origin/feature/driver），但本地并没有一个可以直接修改的 feature/driver 分支。直接 checkout 远端分支会导致 detached HEAD 状态，无法安全提交。
三、创建本地开发分支
这是最核心的步骤。永远不要直接在 origin/xxx 上开发。
✅ 正确做法是基于远端分支创建本地分支并切换过去：
git switch -c feature/kaifa origin/feature/driver
旧版本 Git 也可以用：
git checkout -b feature/kaifa origin/feature/driver
这一步同时完成两件事：以公司分支为起点创建你自己的本地分支，并立即切换到该分支。此时结构如下：
feature/kaifa：本地可写分支origin/feature/driver：远端只读快照
四、开发与提交
在本地分支上，你只需要专注做一件事：写代码。
1. 查看改动
git status
git diff
2. 暂存修改
将想提交的文件加入暂存区：
git add .
3. 提交到本地分支
git commit -m "feat: 完成 xxx 功能"
注意：git commit 只会进入当前的本地分支，不会影响远端的任何内容。这是一个最小闭环，保证本地历史清晰。
五、推送到远端协作
首次推送建议使用 -u 参数，这会在远端创建分支并建立本地与远端的跟踪关系。
git push -u origin feature/kaifa
之后每次推送只需输入：
git push
六、开发中的代码同步
同事可能一直在更新 feature/driver，你需要保持同步以避免后续冲突过大。
推荐的安全流程如下：
git switch feature/kaifa
git fetch origin
git merge origin/feature/driver
如果遇到冲突：
- 手动修改冲突文件
git add 冲突文件git commit解决冲突
⚠️ 新人阶段不建议一上来就用 rebase，merge 更直观且不易出错。
七、提交 PR / MR 合并
功能开发完成并 push 后，远端有了你的 feature/kaifa，而主开发在 feature/driver。
正规流程是：
- 在 GitLab / GitHub / Gitee 上创建 MR/PR
- 目标分支选择
feature/driver - 等待评审通过合并
- 合并后本地再同步一次最新的
feature/driver
八、常见错误与避坑总结
回顾一下容易踩的坑：
- ❌ 在
origin/xxx上直接开发 - ❌ 在 detached HEAD 状态下长期写代码
- ❌ 不区分 fetch / merge / pull 的区别
- ❌ 把'远端分支'当成'本地分支'使用
✅ 核心认知：
origin/xxx= 只读快照- 本地分支 = 唯一可开发实体
- 提交必须有分支承载
记住一点：git clone 只是同步远端状态，真正的开发永远从'基于 origin/xxx 创建本地分支'开始。
