【GIT】GIT 的基本应用
【GIT】GIT 的基本应用
- Git 基础用法
- 1. 初始化仓库
- 2. 添加 `.gitignore` 文件
- 3. 项目的暂存与提交
- 理想 vs 现实
- Git 操作命令
- 4. GIT 分支管理
- GIT分支的理解
- 常用分支操作命令
- 5. Tag 标签
- 6. 远程仓库与同步（GitHub）
Git 基础用法
1. 初始化仓库
# 进入你的项目文件夹
cd /path/to/your/project# 初始化 Git 仓库
git init
你也可以通过 VS Code 的图形界面点击“初始化仓库”按钮来完成这一步。
2. 添加 .gitignore 文件
建议在项目根目录下立即创建一个 .gitignore 文件，用来告诉 Git 忽略哪些文件和文件夹（如编译产物、日志、IDE 配置等）。
以下是一个适用于 ROS 项目的 .gitignore 模板，满足大多数常见需求，可根据实际项目自行调整：
# =========================
# ROS / Catkin / Colcon
# =========================
build/
devel/
install/# 日志文件
log/
logs/
*.log# 编译数据库
compile_commands.json
.catkin_tools/# =========================
# IDE / 编辑器配置
# =========================
.vscode/
.idea/
*.swp
*~
.DS_Store# =========================
# Python 缓存
# =========================
__pycache__/
*.pyc
*.pyo# =========================
# 临时文件 / 编译产物
# =========================
*.so
*.a
*.out
3. 项目的暂存与提交
在使用 Git 管理代码时，我们需要理解两个核心概念：
- 暂存（Staging）：将修改过的文件加入 Git 的“暂存区”，相当于准备好哪些内容要被提交。
- 提交（Commit）：将“暂存区”的内容正式保存到本地 Git 仓库中。
注意：提交只是保存到本地仓库，并不会同步到远程仓库（如 GitHub、Gitee 等）！
PS： VS Code 提交说明
VS Code 的 Git 面板通常会自动将所有修改的文件暂存，然后一键提交。这虽然方便，但在实际开发或竞赛中，不建议总是使用“一键提交”，因为这样会让提交记录变得混乱、不清晰。
理想 vs 现实
-
理想情况：你接到一个任务“修复Bug A”。你非常专注，只修改了和Bug A相关的文件，然后立刻提交，写上 “Fix: 修复Bug A”。接着，你再接到任务“开发功能B”，再专注地完成并提交。
-
现实情况（尤其是在高压的竞赛调试中）：
你在试图修复那个烦人的“Bug A”时，你的思维是发散的。你可能会经历这样一个混乱的过程：- “嗯，是不是 path_planner.cpp 里的逻辑错了？” —— 你改了 path_planner.cpp。
- “为了验证我的修改，我得在 main.cpp 里加一句打印日志的代码看看。” —— 你改了 main.cpp。
- “哦，日志显示是参数问题。我去 params.yaml 里调一下 max_velocity。” —— 你改了 params.yaml。
- “顺便，我早就想把 README.md 里的一个错别字改了，现在正好想起来了。” —— 你改了 README.md。
- “啊哈！终于搞定了！原来是 path_planner.cpp 和 params.yaml 配合的问题。”
现在，Bug A 修复了。你准备提交。此时，你的工作区里有4个文件被修改了：
- path_planner.cpp (核心修复)
- params.yaml (核心修复)
- main.cpp (包含了临时的调试代码)
- README.md (一个完全不相干的错别字修改)
此时你会发现，真正解决 Bug A 的关键在于对 path_planner.cpp 和 params.yaml 的修改，而其他两个文件的改动（main.cpp 的调试代码和 README.md 的错别字）与 Bug A 无关。
如果这时你使用 VS Code 的“一键提交”功能，会将所有改动一次性提交，导致提交记录杂乱，不利于后期追踪和协作。
因此，建议你只将 path_planner.cpp 和 params.yaml 暂存并提交
其余两个文件的修改可以暂时保留在工作区中，待后续清理或单独提交，避免不同类型的修改混在一起。
Git 操作命令
1. 添加文件到暂存区：
git add <文件路径> # 添加指定文件
git add . # 添加当前目录下所有修改文件（不建议盲用）
2. 提交暂存区的修改：
git commit -m "提交的备注信息"
3. 快速提交（ 暂存 + 提交）：
git commit -a -m "提交说明" # 会自动添加所有已追踪（已 add 过的）文件的修改
你也可以在 VS Code 的 Git 面板中点击“提交”按钮，这实际上也是暂存+提交
4. 删除历史提交（交互式修改提交记录）
使用 git rebase -i 命令可以对历史提交进行精细调整，比如删除某一条不必要的提交：
git rebase -i <commit_id>
此命令会打开交互式编辑页面，列出从指定 commit 之后的所有提交：
例如：
pick c4d5e6f Commit C: 一个多余的提交
pick f7g8h9i Commit D: 一个有用的提交
将不需要的提交前的 pick 改为 drop，或删除整行：
drop c4d5e6f Commit C: 一个多余的提交
pick f7g8h9i Commit D: 一个有用的提交
- 图形化方式（推荐初学者使用）
使用 Git Graph 插件（VS Code）也可以完成删除提交、合并提交、变基等操作：
4. GIT 分支管理
强烈建议使用 VS Code 的 Git Graph 插件，可以清晰地可视化分支和提交历史，非常适合分支管理。
教程参考：【VSCode ☆ Git 】代码管理进阶 ➔ Git Graph 插件
GIT分支的理解
1. 分支的本质：它不是副本，只是一个“名字标签”
一个分支（比如 main 或 dev）并不是项目代码的一份完整拷贝。它极其轻量，本质上只是一个**“名字标签”**（或者叫“指针”、“书签”）。
2. “名字标签”贴在哪里？—— 贴在“最尾”的提交上
这个“名字标签”是动态的，它总是指向它所在路径上的最新一次提交。如果我在 dev 分支上连续做了三次提交，那么 dev 这个标签就会自动从第一次提交移动到第二次，再移动到第三次，始终粘在“最尾部”，代表着这条开发路径的当前进展。
3. 所有分支的共同源头：第一次提交
无论我有多少个分支，比如 main、dev、feature-A 等等，它们看似是不同的路径，但如果顺着各自的提交历史往回追溯，最终都会汇集到同一个起点——那就是我这个项目的第一次提交。这就像一棵树，无论有多少枝丫，都源于同一个树根。
4. 创建分支的真正含义：在当前节点多贴一张标签
当我站在某个提交（比如 D）上，执行 git checkout -b dev 命令时，我所做的事情仅仅是：在 D 这个提交节点上，多贴了一张新的、名为 dev 的“名字标签”。此刻，main 和 dev 这两张标签都贴在同一个提交 D 上。从这一刻起，我切换到 dev 分支上工作，新的提交只会让 dev 标签向前移动，而 main 标签则会留在原地，从而实现了两条路径的分离。
5. 删除分支的真正含义：撕掉一张标签
我删除了 master 分支，但发现 dev 分支的历史还在。这是因为我只是 撕掉了贴在某个提交上的那张名为 master 的“名字标签”而已 。只要还有其他标签（比如 dev）指向那个提交或者它的后续提交，那么整个提交历史链条就是安全的，不会丢失。提交节点（历史本身）的存亡，取决于它是否能被任何一个“名字标签”追溯到。
总结成一句话：
整个项目的历史是由一个个“提交节点”构成的树，而分支仅仅是贴在树上某个特定“叶子节点”上的、可以随时移动和增删的“名字标签”。
常用分支操作命令
1. 创建并切换到一个新分支
git checkout -b develop
-b 表示“branch”，该命令会创建一个名为 develop 的新分支并立即切换过去。
例如：
2. 切换到已有分支
git checkout develop
和上面相比，这里没有 -b 参数，只表示切换到一个已经存在的分支。
3. 查看当前所在分支
git branch
4. 删除分支
git branch -d master
5. 时间回溯、版本回退
-
- 仅查看旧版本（不影响历史）
git checkout <commit_id>
这只是临时查看指定版本的代码，不会改变当前分支。查看完后，可用 git checkout main 切回原分支。
也可以通过图形界面操作：
-
- 永久回退到旧版本（删除之后的提交）
git reset --hard <commit_id>
该命令会将当前分支重置到指定版本，并清除之后的所有提交记录。
也可以通过图形界面操作：
注意事项：
reset --hard是不可逆的，操作前请确认不再需要后续提交。- 如果已经推送到远程仓库，回退后需使用
git push -f强制推送，但可能会影响他人协作，慎用。
5. Tag 标签
Tag（标签）用于给某次提交做标记，方便以后快速查找和识别，比如标记为“稳定版本”“测试版”等。它类似于给提交打个名字。
命令行方式
- 为当前提交打标签：
git tag -a <tag_name> -m <"message">
git tag -a v0.9-stable -m "资格赛最终版，稳定跑通全程"
- 为指定的某次提交打标签（通过 commit ID）：
git tag -a <tag_name> -m <"message"> <message_id>
git tag -a v0.9-stable -m "3圈80s，TEB稳定" c7d4b8e
图形化方式（推荐）
使用 Git Graph 插件，在界面中右键选择某次提交，即可添加标签，更直观方便：
6. 远程仓库与同步（GitHub）
将本地项目同步到 GitHub 的主要步骤如下：
1. 先创建远程仓库（建议）
建议先去 GitHub 新建一个空仓库，填写仓库名称和描述。这样仓库更有条理，名字和说明也更清晰。
2. 与远程仓库建立连接
推荐用 VS Code 的图形界面操作，如下图所示，通常会将远程仓库命名为 origin（默认即可）：
验证连接是否成功：
git remote -v
如果输出如下，就说明连接成功：
origin https://github.com/your-username/your-project-name.git (fetch)
origin https://github.com/your-username/your-project-name.git (push)
3. 推送到远程仓库
了解：
推送（git push）是指将我本地分支上所有领先于远程分支的提交，作为一个整体（一个提交链），一次性地上传同步到 GitHub 仓库中。我在本地新增了多少个 commits，推送成功后，GitHub 仓库里就会对应地增加多少个 commits。
- 第一次推送（推荐加上 -u）
# 第一次推送 main 分支
git push -u origin main# 第一次推送 dev 分支
git push -u origin dev
-u表示设置本地分支与远程分支的关联。设置好之后，以后可以直接用git push或git pull，无需写分支名。
- 后续日常推送
git push
默认会将当前分支的修改推送到远程仓库。
4. VS Code 图形化推送（更简单）
-
第一次推送：点击“发布分支”
-
后续推送：点击“同步更改”
