拉取、提交、分支，都属于 Git ------ 这是一个分布式版本控制系统。
团队中在拉取、提交、分支是在干什么？ 他们在多人协作修改同一个巨大的代码库，同时保证：
-
互不干扰：A在调ACC算法，B在写避障逻辑，两人并行工作。
-
有后悔药：改错了可以随时回退到昨天的版本。
-
代码安全：不会因为一个人删了文件，导致所有人的代码都跑不起来。
一、 核心概念
如果你们维护着一个代码仓库
| 术语 | 英文 | 通俗解释 | 对应场景 |
|---|---|---|---|
| 仓库 | Repository (Repo) | 存放所有代码和历史记录的地方。分为"远程仓库"（公司服务器/GitLab）和"本地仓库"（你电脑上的）。 | 整个项目文件夹 |
| 分支 | Branch | 平行宇宙 。主分支（通常叫 master 或 main）是稳定版代码。你想改代码，就复制一个平行宇宙（功能分支），在里面怎么改都不会影响主宇宙。 |
"我先建个副本试着改一下PID参数" |
| 拉取 | Pull | 同步。把远程仓库里别人写好的最新代码，下载到你的电脑里。 | "上班第一件事，先把昨晚同事的代码同步下来" |
| 暂存 | Stage / Add | 挑选。你改了10个文件，但只想提交其中3个。你把这3个放入"暂存区"。 | "把修改好的文件挑出来，准备打包" |
| 提交 | Commit | 存档。把暂存区的文件生成一个永久的记录点（节点）。每个提交都有一个唯一的ID。 | "保存进度，写上备注：优化了弯道速度规划" |
| 推送 | Push | 上传。把你本地的"存档"上传到公司的服务器上。 | "我改完了，上传给你们看" |
| 合并/PR/MR | Merge / Pull Request | 申请合入。你在平行宇宙改好了，发起一个请求，让组长（Mentor）审核，审核通过后，把你的代码合并进主分支。 | "代码写好了，求Review，求合入" |
二、 一图看懂 Git 工作流
为了直观理解数据是如何流动的，请看下面的图解：
-
Workspace: 你的工作区（写代码的地方）。
-
Staging Area: 暂存区（购物车，准备提交的文件）。
-
Local Repository: 本地仓库（你的私人存档）。
-
Remote Repository: 远程仓库（公司的公共存档）。
三、"保姆级"操作流程
假设接到一个任务：优化纯追踪（Pure Pursuit）算法的预瞄距离。按照标准流程，你需要这样做：
第一步：上班打卡，同步代码（Pull）
防止你在基于旧代码工作，每天开始写代码前，务必先同步！
# 1. 切换到主分支 (通常是 master 或 main)
git checkout master
# 2. 从远程仓库拉取最新代码
git pull origin master第二步：创建你的分支Branch（相当于一个平行宇宙）
千万不要直接在 master 分支上改代码！ 这是大忌。一定要新建分支。
# 创建并切换到一个叫 fix-lookahead-dist 的分支
# -b 表示 create branch
git checkout -b fix-lookahead-dist第三步：写代码（Coding）
打开你的 IDE（VSCode/CLion），修改算法逻辑。
第四步：保存你的修改（Add & Commit）
代码改好了，自测也没问题了。
# 1. 查看改了哪些文件
git status
# 2. 把修改的文件加入暂存区 ( . 代表所有文件)
git add .
# 3. 提交并写备注 (备注要清晰，不要写 "fix" 这种废话)
# 格式推荐：[模块名] 修改内容
git commit -m "[Control] 优化纯追踪预瞄距离策略，解决低速抖动问题"第五步：上传代码（Push）
把你的分支上传到公司服务器或者git仓库。
# 把当前分支推送到远程 origin 仓库
git push origin fix-lookahead-dist第六步：发起合并请求（MR / PR）
这一步通常在网页上操作（GitLab 或 GitHub）：
-
打开代码仓库网页。
-
你会看到提示"New branch pushed..."。
-
点击 "Create Merge Request" (GitLab) 或 "Pull Request" (GitHub)。
-
Assignee 选你自己，Reviewer 选你的导师（Mentor）。
-
点击创建。
此时，你的导师会收到通知："实习生提交代码了，请审核。" 他看完代码没问题，点击 "Merge"，你的代码就正式进入项目主线了！
四、 规划控制岗位的特殊 Git 注意事项
有几个坑新手最容易踩，请务必注意：
-
不要提交大文件（Rosbag/Log）：
-
规划控制调试经常需要录包（
.bag或.mcap文件），动不动几百 MB 甚至几个 GB。 -
千万不要
git add .把这些数据包也提交上去！仓库会瞬间爆炸。 -
解决办法 ：确保目录下有
.gitignore文件，并且里面写了忽略*.bag。
-
-
参数文件与代码分离：
- 如果你只是调参（比如 PID 的 Kp），尽量只提交参数配置文件（
.yaml），不要改动.cpp逻辑，除非逻辑真有问题。
- 如果你只是调参（比如 PID 的 Kp），尽量只提交参数配置文件（
-
编译产物不要提交：
- C++ 编译生成的
build/,install/文件夹，或者可执行文件，不需要提交。
- C++ 编译生成的
五、 我该怎么做？（下一步行动）
-
配置环境（如果你还没配）：
git config --global user.name "YourName" git config --global user.email "your_email@company.com" -
多用
git status： 在执行任何命令前，都养成敲一下git status的习惯，看看自己当前在哪个分支，改了哪些文件。 -
不要怕问： 如果执行命令报错了（比如出现 "Conflict" 冲突），千万不要瞎操作强行覆盖，截图发给你的 Mentor 问："我 Pull 的时候有冲突，该怎么解？"这是最安全的做法。