Git 开发全流程：一套不踩坑的 Git 团队开发完整流程（小白教程）

目录

文章摘要

一、为什么一定要规范 Git 开发流程？

二、准备阶段：确认你是谁（只需一次）

三、第一步：克隆公司仓库（git clone）

四、第二步：拉取远端最新快照（团队习惯：先 fetch 再看）

五、第三步：从远端快照创建你的本地开发分支（核心步骤）

六、第四步：在本地分支上开发与提交（写代码 → add → commit（最小闭环）

6.1 查看改动

6.2 暂存修改

6.3 提交到本地分支

七、第五步：推送到远端，参与团队协作

八、第六步：开发过程中如何同步公司最新代码（高频场景）

九、开发完成：提交 PR / MR 合并回公司分支（团队标准闭环）

十、常见错误与易踩坑总结

文章摘要

在实际工程开发中，很多 Git 问题并不是不会写代码，而是分支用错了：

• 直接在origin/xxx上开发

• 不知道为什么进入了 detached HEAD

• 提交后代码“丢了”

• git pull、fetch、merge概念混乱

本文从 0 开始，完整讲清一套真实公司通用的 Git 开发流程，从git clone到创建本地开发分支，再到开发、同步、提交、合并，一步不省，一坑不跳。

适合人群：

• Git 新手 / 刚进公司

• 经常被分支问题卡住的开发者

• 想把 Git 用得更“工程化”的同学

一、为什么一定要规范 Git 开发流程？

在公司环境中：

• ❌不能直接在公司主分支上开发

• ❌不能在远端分支（origin/xxx）上提交

• ❌不能依赖“反正能 push 上去”

你真正需要的是：

一条清晰的、可回滚、可协作、可评审的开发链路

而这条链路，一定从git clone开始。

二、准备阶段：确认你是谁（只需一次）

git config --global user.name "XXXX" git config --global user.email "xxx@xxx.com"

查看是否生效：

git config --global -l

三、第一步：克隆公司仓库（git clone）

git clone <repo_url> cd <repo_dir>

很多人以为git clone只是“把代码拷下来”，但实际上它自动做了 4 件事：

1️⃣创建一个本地 Git 仓库
2️⃣ 添加远端仓库，默认命名为origin
3️⃣自动执行一次git fetch origin
4️⃣ 生成远端跟踪分支（如origin/feature/driver）

你可以验证：

git status git branch git branch -a

你通常会看到：

* main remotes/origin/main remotes/origin/feature/driver

你会看到类似：

• 本地：main（或master/dev）

• 远端跟踪分支：remotes/origin/feature/driver等

⚠️注意重点：

clone 下来的是“远端快照 origin/xxx”，
本地并没有 feature/driver 这个可开发分支

四、第二步：拉取远端最新快照（团队习惯：先 fetch 再看）

git fetch origin

然后确认远端有哪些分支：

git branch -r

比如你发现公司主开发分支是：

origin/feature/driver

五、第三步：从远端快照创建你的本地开发分支（核心步骤）

永远不要直接checkout origin/feature/driver做开发（会 detached HEAD）

✅ 正确做法：

git switch -c feature/kaifa origin/feature/driver

（旧写法等价）

git checkout -b feature/kaifa origin/feature/driver

这一步同时完成：

• 以公司分支为起点

• 创建你自己的本地分支

• 并立即切换到该分支

• 本地可写分支：feature/kaifa

• 基于只读快照：origin/feature/driver

此时结构是：

feature/kaifa（本地 · 可开发） | o───o───o origin/feature/driver（远端 · 只读） | o───o───o

六、第四步：在本地分支上开发与提交（写代码 → add → commit（最小闭环）

此时你只做一件事：

只在 feature/kaifa 上写代码

6.1 查看改动

git status git diff

6.2 暂存修改

git add .

6.3 提交到本地分支

git commit -m "feat: 完成 xxx 功能"

⚠️ 一个关键认知：

git commit只会进入 feature/kaifa（本地）

不会影响origin/feature/driver。

七、第五步：推送到远端，参与团队协作

首次推送建议使用：

git push -u origin feature/kaifa

-u 作用是：

• 在远端创建feature/kaifa

• 建立本地与远端的跟踪关系

之后你只需要：

git push

八、第六步：开发过程中如何同步公司最新代码（高频场景）

公司同事一直在更新feature/driver，你需要同步。

推荐安全流程（工程常用）

git switch feature/kaifa git fetch origin git merge origin/feature/driver

如果有冲突：

1️⃣ 修改冲突文件
2️⃣git add 冲突文件
3️⃣git commit

⚠️ 新人阶段不建议一上来就 rebase

九、开发完成：提交 PR / MR 合并回公司分支（团队标准闭环）

做完功能并 push 后：

• 远端有feature/kaifa

• 公司主开发在feature/driver

✅ 正规流程是：

1）在 GitLab / GitHub / Gitee 上创建 MR/PR
2）目标分支：feature/driver
3）评审通过后合并
4）你本地再同步一次最新feature/driver

十、常见错误与易踩坑总结

❌ 在origin/xxx上开发
❌ detached HEAD 状态下长期写代码
❌ 不区分 fetch / merge / pull
❌ 把“远端分支”当“本地分支”

✅ 正确认知：

• origin/xxx = 只读快照

• 本地分支 = 唯一可开发实体

• 提交必须有分支承载

git clone 只是同步远端状态；
真正的开发，永远从“基于 origin/xxx 创建本地分支”开始。