Git基础——add/commit/push/branch的正确使用姿势-平芜编程栈

面试的时候被问过一个问题："你平时怎么管理代码？"我当时脑子一抽，说了句"用U盘备份"。面试官笑了，我也笑了。但那个笑，比挂了还难受。

后来才知道，Git是机器人开发团队里最基础的工具，没有之一。不管你是做算法的还是搞嵌入式的，不会Git基本上就没法进团队。今天就把Git最核心的几个操作掰开了讲，让你面试的时候不再心虚。

git init和git clone：从零开始

两种情况。一种是你有个新项目，啥都没有：

mkdir my_robot_project cd my_robot_project git init

这时候当前目录就变成了一个Git仓库。Git会在里面创建一个.git隐藏文件夹，用来跟踪所有变更。

另一种是团队已经有现成的仓库了，你需要把它拉下来：

git clone git@github.com:team/robot_project.git

这行命令会在本地创建一份完整副本，包括所有历史记录。注意，不是只拿最新版本，是全部历史都拿。这就是分布式版本控制的核心思想。

clone下来之后，你会看到一个.git目录。别碰它。删了它你就丢失了所有版本历史。

git add和git commit：最基本的提交

改完代码之后，第一步是告诉Git"我改了哪些文件"：

git status # 看看哪些文件变了 git add main.cpp # 把main.cpp加入暂存区 git add src/ # 把src目录下所有改动都加入 git add . # 把所有改动都加入（慎用）

git add这一步很关键。它不是提交，只是告诉Git"这些改动我准备提交了"。你可以选择性地只add一部分文件，比如你改了两个bug，但只想先提交其中一个。

然后是真正的提交：

git commit -m "修复了激光雷达数据解析的bug"

commit message写清楚，这是给未来的自己看的。别写"fix bug"这种废话，过一个月你自己都不知道fix了啥。

有个实用技巧：git add -p。这个命令可以按代码块（hunk）来添加，而不是整个文件。比如你改了一个文件里的两处代码，只想提交其中一处，用-p就能精确选择。面试的时候提到这个，面试官会觉得你是真用过Git的。

.gitignore：别把不该提交的东西传上去

每个项目根目录都应该有个.gitignore文件。它告诉Git哪些文件不需要跟踪。

典型的机器人项目.gitignore：

build/ devel/ install/ *.pyc .vscode/ *.swp core_dump

编译产物、IDE配置、Python缓存文件，这些都不应该提交。我之前见过一个实习生把整个build目录都commit进去了，几万个文件，仓库直接膨胀到2个G。后来花了好大力气才从历史里清掉。

git branch：分支的正确用法

分支是Git最强大的功能。你可以把它理解为"平行宇宙"——在主线之外开一条线，随便改，改好了再合并回去。

git branch # 查看所有分支 git branch feature_lidar # 创建新分支 git checkout feature_lidar # 切换到该分支 git checkout -b feature_lidar # 创建并切换（上面两步合一）

在机器人项目里，常见的分支策略是这样的：main分支永远是稳定可发布的版本，develop是日常开发的主线，然后每个功能或者bugfix单独开一个分支。比如你要加一个IMU驱动，就开个feature_imu_driver分支，开发完了再合并回develop。

千万别在main分支上直接改代码。这不是小项目两三个人随便搞搞的时代了，正经团队都有分支规范。

git push和git pull：远程同步

本地commit之后，代码还在你自己电脑上。要推到远程仓库让团队看到：

git push origin feature_lidar # 把本地分支推到远程 git push -u origin feature_lidar # 第一次push时加-u，建立追踪关系

-u这个参数只在第一次用。之后直接git push就行了，Git已经记住了你要推到哪里。

从远程拉取更新用git pull：

git pull origin develop

这其实是两个操作的组合：先从远程下载（fetch），再合并到本地（merge）。

这里有个新手常踩的坑：你在本地改了代码，同事也改了，你pull的时候就会冲突。冲突不可怕，后面会专门讲。但你要养成一个习惯——开始工作前先pull一下，保持本地和远程同步，能减少很多不必要的冲突。

git log和git diff：查看历史

git log # 查看提交历史 git log --oneline # 简洁模式，一行一个commit git log --graph # 图形化显示分支合并 git diff # 查看当前改动和上次commit的差异 git diff HEAD~1 # 查看和上一个commit的差异

git log --oneline --graph --all这个组合命令特别好用，能看到整个项目的分支历史全貌。排查问题的时候特别有用。

机器人开发中的Git实践

在机器人项目里，Git的使用有一些特殊注意事项。

大文件问题。机器人项目经常涉及数据集、模型文件、地图文件这些动辄几百MB的东西。直接提交到Git里会让仓库变得巨大。解决办法是用Git LFS（Large File Storage）：

git lfs install git lfs track "*.pcd" git lfs track "*.bag"

这样大文件会被LFS管理，不会撑爆仓库。

多语言混合项目。一个典型的机器人项目可能同时有C++、Python、Launch文件、配置文件。建议按功能模块组织目录结构，而不是按语言分。这样在分支管理的时候，一个功能的改动集中在一个目录里，review起来方便。

编译缓存。ROS项目的编译时间很长，有时候编译产物会不小心被Git跟踪。一定要在.gitignore里排除build/、devel/、install/这些目录。

面试中怎么聊Git

面试官问Git，通常不是让你背命令。他们想看的是：你有没有在真实项目中用过，有没有遇到过问题，怎么解决的。

你可以这样回答："我们项目用Git Flow的分支模型，main是稳定版本，develop是开发主线。每个功能开feature分支，开发完提PR做code review。有一次我push了一个commit把编译产物也提交进去了，仓库从50M涨到800M，后来用git filter-branch从历史里清掉的。从那以后我特别重视.gitignore的配置。"

这种回答比背十个命令都有说服力。因为它说明你真的用过，真的踩过坑，真的解决了问题。

Git分支管理的实战经验

在实际项目中，Git分支管理策略很重要。一个简单有效的策略是：main分支始终保持可发布状态，开发在feature分支上进行，完成后通过PR合并。常见的错误包括：在main上直接修改、忘记拉取远程更新就push、解决冲突时不小心覆盖别人的代码。一个实用的习惯是每次开始工作前先git pull --rebase，保持本地分支干净。

补充一个实用技巧：git log --oneline --graph --all 可以可视化查看完整的分支历史，排查问题时特别方便。另外git diff --stat可以快速了解一次提交改了多少文件。

掌握这些Git技巧，团队协作效率会大幅提升。