Git 相关操作大全

拉取、提交、分支，都属于 Git ------ 这是一个分布式版本控制系统。

团队中在拉取、提交、分支是在干什么？ 他们在多人协作修改同一个巨大的代码库，同时保证：

1. 互不干扰：A在调ACC算法，B在写避障逻辑，两人并行工作。

2. 有后悔药：改错了可以随时回退到昨天的版本。

3. 代码安全：不会因为一个人删了文件，导致所有人的代码都跑不起来。

---

一、 核心概念

如果你们维护着一个代码仓库

术语	英文	通俗解释	对应场景
仓库	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）：

1. 打开代码仓库网页。

2. 你会看到提示"New branch pushed..."。

3. 点击 "Create Merge Request" (GitLab) 或 "Pull Request" (GitHub)。

4. Assignee 选你自己，Reviewer 选你的导师（Mentor）。

5. 点击创建。

此时，你的导师会收到通知："实习生提交代码了，请审核。" 他看完代码没问题，点击 "Merge"，你的代码就正式进入项目主线了！

---

四、 规划控制岗位的特殊 Git 注意事项

有几个坑新手最容易踩，请务必注意：

1. 不要提交大文件（Rosbag/Log）：

   • 规划控制调试经常需要录包（.bag 或 .mcap 文件），动不动几百 MB 甚至几个 GB。

   • 千万不要 git add . 把这些数据包也提交上去！仓库会瞬间爆炸。

   • 解决办法 ：确保目录下有 .gitignore 文件，并且里面写了忽略 *.bag。

2. 参数文件与代码分离：

   • 如果你只是调参（比如 PID 的 Kp​），尽量只提交参数配置文件（.yaml），不要改动 .cpp 逻辑，除非逻辑真有问题。

3. 编译产物不要提交：

   • C++ 编译生成的 build/, install/ 文件夹，或者可执行文件，不需要提交。

五、 我该怎么做？（下一步行动）

1. 配置环境（如果你还没配）：

   git config --global user.name "YourName"
   git config --global user.email "your_email@company.com"

2. 多用 git status： 在执行任何命令前，都养成敲一下 git status 的习惯，看看自己当前在哪个分支，改了哪些文件。

3. 不要怕问： 如果执行命令报错了（比如出现 "Conflict" 冲突），千万不要瞎操作强行覆盖，截图发给你的 Mentor 问："我 Pull 的时候有冲突，该怎么解？"这是最安全的做法。