3、Git常用操作：commit、push、pull、branch、merge的基本使用
好，咱们直接进入正题。Git这东西，说白了就是给代码拍快照、做备份、搞协作。我在窗帘电机项目里，每天跟这几个命令打交道。你想想看，一个团队五六个人，同时改着电机驱动、蓝牙协议、上位机接口，没有Git，那不乱成一锅粥？
今天我就把这五个最常用的操作，掰开了揉碎了讲给你听。嗯，都是实战里摸爬滚打出来的经验。
3.1 commit：给你的代码拍个“定妆照”
commit 是Git最基础的操作。它的作用，就是把当前工作区的改动，保存成一个“版本快照”。
我个人习惯是：小步提交，频繁提交。别攒了一堆改动才commit一次，那样出了问题你都不知道是哪一步搞坏的。
核心原则：每次commit应该是一个逻辑完整的改动。比如“修复了电机堵转时的PWM输出异常”，而不是“改了一些东西”。
基本用法：
# 把文件加入暂存区
git add motor_driver.c
git add protocol_handler.c
# 提交到本地仓库
git commit -m "修复电机堵转时PWM输出异常，增加超时保护机制"我在项目中遇到过一个问题：有同事commit信息写的是“fix bug”，过了两周回头看，谁还记得这个bug是啥？所以，commit信息一定要写清楚“改了啥”和“为什么改”。
我的小技巧：commit信息用“动词+对象+原因”的格式。比如：“增加电机堵转检测逻辑，防止长时间过流烧毁驱动芯片”。这样别人一看就懂。
3.2 push：把你的代码推送到远程仓库
commit 只是把代码存到了你本地电脑上。要想让队友看到，或者备份到服务器，就得用 push。
说白了，push 就是把本地仓库的commit，同步到远程仓库（比如GitHub、GitLab或者公司自建的Git服务器）。
# 第一次推送，建立关联
git push -u origin master
# 后续推送
git push嗯，这里要注意：push之前，一定要先pull。我曾经有一次没pull就直接push，结果把队友刚改好的蓝牙配对代码给覆盖了……那场面，别提多尴尬了。
避坑指南：push前先执行 git pull --rebase，把你的改动放在远程最新代码的“上面”，这样提交历史更干净。我吃过亏，现在每次push前都条件反射地先pull。
3.3 pull：把远程代码拉下来，保持同步
pull 是 fetch + merge 的组合操作。它先从远程仓库下载最新代码，然后自动合并到你当前的分支。
你想想看，早上到公司，第一件事就是 git pull，看看队友昨晚有没有偷偷提交代码。这是团队协作的日常。
# 拉取远程master分支的最新代码
git pull origin master
# 推荐用法：用rebase方式拉取，避免产生多余的merge commit
git pull --rebase origin master我个人强烈推荐用 git pull --rebase。为什么？因为普通的 git pull 会产生一个“merge commit”，把提交历史搞得乱七八糟。用rebase方式，你的提交会“垫”在远程最新代码的后面，历史是一条直线，看着清爽。
经验之谈：如果你在pull时遇到冲突，别慌。Git会提示哪些文件冲突了，手动解决后 git add 再 git rebase --continue 就行。我刚开始用Git时，一看到冲突就头皮发麻，后来发现其实就那么回事。
3.4 branch：分支管理，并行开发的利器
分支是Git最强大的功能之一。没有分支，大家只能排队改代码，效率极低。有了分支，你可以同时开发多个功能，互不干扰。
在窗帘电机项目里，我们通常这样分：
| 分支名称 | 用途 | 说明 |
|---|---|---|
| master | 主分支 | 只放稳定版本，不能直接在上面改代码 |
| develop | 开发分支 | 日常开发的主战场，功能开发从这里拉分支 |
| feature/xxx | 功能分支 | 比如 feature/motor-protocol，开发完合并回develop |
| hotfix/xxx | 紧急修复分支 | 线上出bug时，从master拉出来修，修完合并回master和develop |
# 创建并切换到新分支
git checkout -b feature/motor-protocol
# 查看所有分支
git branch -a
# 切换分支
git checkout master我记得有一次，我们同时开发三个功能：电机堵转检测、蓝牙OTA升级、上位机日志系统。三个开发人员各拉一个分支，各改各的，互不影响。等各自测试通过后，再合并到develop分支。这就是分支的魅力。
重要提醒：分支命名要有规范。别用“test”、“mybranch”这种名字，过两天你自己都忘了这个分支是干嘛的。推荐格式：类型/功能描述，比如 feature/ota-upgrade、hotfix/pwm-overflow。
3.5 merge：把分支的成果合并到一起
分支开发完了，总得合回来吧？merge 就是干这个的。它把另一个分支的改动，合并到你当前所在的分支。
基本用法：
# 先切换到目标分支（比如develop）
git checkout develop
# 把feature分支合并进来
git merge feature/motor-protocol合并时可能会遇到冲突。比如你和队友都改了 motor_driver.c 的第100行，Git不知道该听谁的，就会报冲突。
解决冲突的步骤：
- Git会告诉你哪些文件冲突了，用
git status查看 - 打开冲突文件，找到
<<<<<<<、=======、>>>>>>>标记的区域 - 手动选择保留哪部分代码，或者重新写一段
- 删掉那些标记符号
- 保存文件，执行
git add和git commit
核心要点：合并前确保你的分支已经测试通过。别把有bug的代码合并到主分支，那是给自己和队友挖坑。我见过有人把未测试的代码直接merge到master，结果整个项目编译不过，一群人排查了半天。
3.6 实战场景：窗帘电机项目的一天
说了这么多，咱们串起来看看。假设你在做窗帘电机项目，一天的工作流程大概是这样的：
# 早上到公司，拉取最新代码
git checkout develop
git pull --rebase origin develop
# 创建一个新分支，开发电机堵转检测功能
git checkout -b feature/stall-detection
# 写代码... 改了一部分，先保存一下
git add motor_driver.c
git commit -m "增加电机电流采样逻辑"
# 继续写... 又改了一部分
git add motor_driver.c
git commit -m "实现堵转检测算法，阈值设为2A持续500ms"
# 中午了，先推送到远程备份一下
git push -u origin feature/stall-detection
# 下午继续开发，测试通过后，合并到develop
git checkout develop
git pull --rebase origin develop
git merge feature/stall-detection
# 如果有冲突，解决冲突后提交
git push origin develop你看，一天下来，commit、push、pull、branch、merge全用上了。这就是嵌入式开发的日常。
我的建议：刚开始用Git时，别怕犯错。Git几乎所有的操作都可以撤销。比如commit写错了可以用 git commit --amend 修改，push错了可以用 git reset 回退。多练几次就熟了。
好了，这五个操作讲完了。说白了，commit是存本地，push是存远程，pull是同步别人代码，branch是开新线，merge是收线。把这五个玩转了，Git就算入门了。下一章咱们聊聊更高级的操作，比如rebase、cherry-pick这些，到时候你会发现，Git比你想的还要强大。