目录

前言：

一、项目背景（团队创建了新的 driver_class 分支）

1.1 为什么会出现一个新的 feature/driver_class？

1.2 driver_class 与 robot_driver 主线的关系

二、fetch 只是“下载信息”，并不会更新当前分支

2.1 git fetch 拉下来的到底是什么

2.2 fetch ≠ merge，也 ≠ 切换

2.3 如果想把 driver_class 合到旧分支，该怎么做？

2.4 总结几条 Git 常识

2.5 本节总结

三、为什么不能继续使用旧分支

3.1 旧分支基于老版本驱动结构

3.2 driver_class 重构太大，会导致旧分支大量冲突

1）修改/删除冲突（modify/delete）

2）内容冲突（both modified）

3）目录重构导致文件根本不存在

3.3 团队 big refactor 时的标准做法

四、如何基于 driver_class 正确创建自己的开发分支

4.1 方式一：一步到位（快捷方式）

4.2 方式二（推荐）：确保基线最新 → 再创建新分支

1）切到 driver_class

2）同步远程最新代码（重要！）

3）从最新 driver_class 创建你自己的分支

五、以后如何在新分支上开发和提交自己的代码

5.1 你日常开发都在 feature/xz 上进行

5.2 提交到远程（可选）

5.3 每次开始开发前，同步团队最新更新

（1）更新 driver_class

（2）切回自己的分支

（3）合并最新基线

六、完整 Git 工作流总结（可视化流程）

七、总结

前言：

在多人协作的大型项目中，Git 分支管理非常关键。
尤其当团队对某个模块进行“大重构”时，你需要 重新理解新的项目基线，并基于最新分支重新创建自己的开发分支。

本文结合我在 robot_driver 项目中的实际操作，总结：

  • 为什么不能继续使用老版本分支？

  • 什么是 driver_class？为什么它现在是最新驱动基线？

  • 如何基于最新 driver_class 正确创建自己的开发分支？

  • 完整的团队级 Git 工作流怎么建立？

看完本章，你就可以完全按照专业流程操作，进行团队级协作！

在之前的章节中已经介绍了很多关于 git 的知识，以下是传送门：

1）关于 git 的基本指令以及分支介绍：

Git 教程（入门＋实践）-CSDN博客https://blog.csdn.net/m0_58954356/article/details/1540745542）VSCode 和 Git 的可视化流程操作指南：

VSCode + Git 全流程可视化操作指南（超详细保姆级）_vscode git-CSDN博客https://blog.csdn.net/m0_58954356/article/details/1545456163）Git 工作区、暂存区、本地仓库、tracking、origin/dev 概念详解：

Git 最强入门到精通：工作区、暂存区、本地仓库、tracking、origin/dev 全面讲透（图解版）-CSDN博客https://blog.csdn.net/m0_58954356/article/details/1549418754）Git 中 merge、rebase、fetch、pull、stash 等指令的深层次解析：

Git 进阶全解析：变基、合并、撤销、挑选、暂存、同步机制完整讲解（高级篇）-CSDN博客https://blog.csdn.net/m0_58954356/article/details/154947750

一、项目背景（团队创建了新的 driver_class 分支）

1.1 为什么会出现一个新的 feature/driver_class？

在团队的 robot_driver 项目中，你会看到这样的更新提示：

[new branch] feature/driver_class -> origin/feature/driver_class

并在 Gitee 上收到通知：

某某 同事推送了新分支 feature/driver_class
至仓库 xxx有限公司/robot_driver

这说明：

  • 团队正式创建了一个新的 驱动重构分支 driver_class

  • 它是基于项目主线（如 dev）重新开发的重要分支

  • 涉及类结构优化、大量文件重写、协议重构

从 VSCode/Git Graph 也能看到 driver_class 的重构规模：

  • 25 个文件修改

  • 3717 行新增

  • 1774 行删除

  • 提交信息：类结构优化、驱动重构、协议升级等

这意味着：
driver_class = 全新的驱动架构（团队未来的标准版本）

1.2 driver_class 与 robot_driver 主线的关系

你可以理解为：

robot_driver（项目主仓库）
 └── feature/driver_class ← 驱动模块最新基线（每个人都必须基于它开发）

并且 driver_class：

  • 基于主线最新代码创建

  • 代表团队重构后的驱动标准结构

  • 是未来所有驱动开发、优化的统一入口

二、fetch 只是“下载信息”，并不会更新当前分支

在团队新增了一个远程分支（例如最新的重构分支）后，你通常会执行：

git fetch origin

但很多人不知道：fetch 并不会让你的本地代码发生变化。

2.1 git fetch 拉下来的到底是什么

执行 git fetch origin 后，你的终端会看到类似：

[new branch] feature/driver_class -> origin/feature/driver_class

含义是：

1）远程仓库新增了一个分支：

feature/driver_class

2）你的本地创建了对应的“远程跟踪分支”：

origin/feature/driver_class

只是把远程最新状态拉到本地，并没有改变你当前的代码。

2.2 fetch ≠ merge，也 ≠ 切换

执行完 fetch 后，你查看分支：

git branch

可能会看到：

* feature/xz
  dev

这说明：

  • 你仍在自己的 feature/xz 旧分支上

  • 并没有自动切换到 driver_class

  • 也没有自动把 driver_class 的内容合并进来

fetch 只是“同步远程信息”，对你当前分支不做任何修改。

这点非常重要，也是很多开发者混淆的地方。

2.3 如果想把 driver_class 合到旧分支，该怎么做？

你当前在 feature/xz，想把 driver_class 的更新合进来：

git merge origin/feature/driver_class

如果你喜欢 rebase（让提交记录更整洁）：

git rebase origin/feature/driver_class

但这正是你之前遇到大量冲突的原因（后面章节会解释为什么不能这样做）。

2.4 总结几条 Git 常识

命令作用
git fetch拉远程最新分支，但不会改本地分支
origin/xxx代表“远程分支的本地镜像”
git checkout / switch切换或创建本地分支
git merge origin/xxx把远程分支合到你当前分支

2.5 本节总结

git fetch 只“知道了远程有了新分支”，不会自动切到新分支，也不会把新分支合到你当前分支。
必须手动 checkout 或 merge 才会真正改变本地代码。

三、为什么不能继续使用旧分支

当 driver_class 出来后，如果你继续使用旧的 feature/xz（基于原先robot_driver拉的分支），

会遇到非常严重的问题：

3.1 旧分支基于老版本驱动结构

你的旧 feature/xz 是这样创建的：

git checkout -b feature/xz dev / 老版本代码

这意味着：

  • 它的代码结构已经过期

  • 里面的文件与 driver_class 中的新文件不匹配

  • 老逻辑与新框架不兼容

3.2 driver_class 重构太大，会导致旧分支大量冲突

 merge 会产生非常典型的错误日志：

1）修改/删除冲突（modify/delete）

文件在 driver_class 中被删除，在旧分支被修改（冲突）

2）内容冲突（both modified）

<<<<<<< HEAD
旧版本代码
=======
新版本代码
>>>>>>> driver_class

3）目录重构导致文件根本不存在

  • 原来 robot_control_node, robot_control_core 被删除或重写

  • serial_control 逻辑全部重构

  • action、mpc控制逻辑全部换新架构

这些变化导致：

继续在旧分支开发 = 越写越乱，越合越错，不可维护。

3.3 团队 big refactor 时的标准做法

在大规模重构场景中，每个开发者应该：

1）保留旧分支当备份或直接删除
2）切到最新基线（driver_class）
3）重新 checkout 自己的个人开发分支

这不是 Git 限制，而是：

 团队级开发规范

 最干净、最专业、最低冲突风险的做法

四、如何基于 driver_class 正确创建自己的开发分支

有两种方式，都正确，但第二种更专业。

4.1 方式一：一步到位（快捷方式）

git checkout -b feature/xz feature/driver_class

含义：

  • 以 driver_class 当前内容为基础

  • 创建新分支 feature/xz

适合：driver_class 已经是最新的情况

4.2 方式二（推荐）：确保基线最新 → 再创建新分支

1）切到 driver_class

git switch feature/driver_class

2）同步远程最新代码（重要！）

git pull

git pull = git fetch + merge
即：拉取 origin 的最新更新 → 合并到本地 driver_class

保证你基于的是团队最新版本。

3）从最新 driver_class 创建你自己的分支

git switch -c feature/xz

现在你的 feature/xz：

  • 完全基于最新 driver_class

  • 结构全新、干净

  • 可以放心开发，不会冲突

五、以后如何在新分支上开发和提交自己的代码

5.1 你日常开发都在 feature/xz 上进行

git switch feature/xz
# 写代码
git add .
git commit -m "xxx 修改说明"

✔ 你可以在 feature/xz 上自由提交

✔ 不应该在 driver_class 上提交任何代码

driver_class 只能作为基线使用。

5.2 提交到远程（可选）

git push origin feature/xz

5.3 每次开始开发前，同步团队最新更新

完整流程：

（1）更新 driver_class

git switch feature/driver_class
git pull

（2）切回自己的分支

git switch feature/xz

（3）合并最新基线

git merge feature/driver_class

冲突一般很少（除非你改了 driver_class 的核心逻辑）。

六、完整 Git 工作流总结（可视化流程）

                   （团队更新）
                    ↓ git pull = git fetch + git merge
         ┌──────────────────────────────────┐
         │     feature/driver_class         │
         │     （驱动模块最新基线）        │
         └───────────────┬────────────────┘
                         checkout -c
                   ↓
        ┌──────────────────────┐
        │     feature/xz       │
        │（你的开发/学习分支）│
        └───────────┬────────┘
                    ↓ 开发提交
             git add / git commit
                    ↓ 可选 push
             git push origin feature/xz

七、总结

1）driver_class 是现在团队驱动模块的最新基线（必须基于它继续开发）。

2）旧的 feature/xz 基于过时结构，不适合继续使用，合并冲突巨大。

3）正确做法是：删除旧分支 → 切到最新 driver_class → 基于它重建 feature/xz。