版权信息
warning
本文章为博主原创文章。遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
1. 初次使用git
1.1. 必需配置+如何修改配置信息
请配置好 user 和 email。
git config --global user.name "your name"
git config --global user.email "you email"
# 设置默认分支名为main而不是master
git config --global init.defaultBranch main使用 --global 选项以修改全局配置文件。如若省略 --global，则修改仓库配置文件。
配置文件应用优先级： 仓库 > 全局 > 系统。
1.2. 查看git的配置信息
# 查看所有配置信息
git config --list
# 查看系统级配置信息
git config --system --list
# 查看用户级/全局配置信息
git config --global --list
# 查看仓库级配置信息
git config --local --list
# e.g. 如果想要查看指定配置项
git config user.name
2. 开始在项目中使用版本管理
git init3. 将更改提交到暂存区
3.1. 提交
将所有更改提交到暂存区，也可指定单个文件：
git add .3.2. 撤回提交
如果想要撤回提交到暂存区的更改（更改保留，只是从暂存区撤回）：
# 移除单个文件
git restore --staged <文件名>
# 移除特定文件夹下的所有文件
git restore --staged <文件夹名>/
# 移除暂存区里的所有文件（一键清空暂存区）
git restore --staged .--staged 确保仅仅把文件从暂存区里撤出来，而不会修改工作区里写好的代码。
使用 git restore 一定要加
--staged，除非完全理解后果。
3.3. 在提交时永久排除一些文件/文件夹
-
在项目根目录下创建
.gitignore文本文件 -
编辑它，e.g.：
# 忽略所有的 .log 结尾的文件 *.log # 忽略整个 node_modules 文件夹（注意末尾的斜杠） node_modules/ # 忽略 build 目录下的所有文件，但不包括 build/readme.txt build/ !build/readme.txt # 仅忽略根目录下的 config.ini 文件，但不影响子目录中的同名文件 /config.ini
如果你在配置 .gitignore 之前，某些文件已经通过 git add 提交到了 Git 版本库中，那么仅仅修改 .gitignore 是无效的。
要使 .gitignore 重新生效，你需要先将这些文件从 Git 的“追踪缓存”中移除：
# 移除单个已追踪的文件（保留本地物理文件）
git rm --cached <文件路径>
# 移除整个已追踪的文件夹（保留本地物理文件夹）
git rm -r --cached <文件夹路径>
git add .gitignore
# 然后提交这次清理操作
git commit -m "chore: 停止追踪指定文件并更新 .gitignore"--cached 确保该文件仅仅是从 Git 的版本控制系统中被移除，而不会从你的电脑硬盘上被物理删除。
4. 正式提交更改
4.1. 提交更改
git commit -m ”提交描述“在提交时，请规范提交描述。
4.2. 提交描述规范
采用约定式提交 (Conventional Commits)。
-
提交结构
提交结构包含三个部分：Header、Body 和 Footer。
<type>(<scope>): <subject> // 空一行 <body> // 空一行 <footer> -
Header 规范（必填）
scope用于说明本次提交影响的模块或文件范围，建议使用英文。-
示例：
kernel、sensor、gui、i2c、build。 -
如果是跨模块的全局修改，可以省略或写
*。
subject（必填）用于对本次提交的简短描述，建议使用英文，要求：-
动词开头：建议使用一般现在时（例如用
implement而不是implemented，用add而不是added）。 -
不加标点：结尾不需要加句号（
.）。 -
言简意赅：控制在 50 个字符以内。
-
| 类型标识 | 含义 | 场景示例 |
|---|---|---|
feat |
新增功能 (Feature) | 新增一个硬件驱动、实现一个新的调度算法 |
fix |
修复 Bug | 修复内存泄漏、修复中断响应延迟问题 |
refactor |
代码重构 | 剥离传感器解析逻辑（不涉及新增功能或修复bug） |
docs |
文档更新 | 更新 README、修改代码注释 |
style |
代码格式 | 调整缩进、空格、格式化（不影响代码运行的逻辑） |
perf |
性能优化 | 优化上下文切换效率、降低 CPU 占用 |
test |
测试相关 | 增加或更新单元测试 |
chore |
构建或工具变动/杂项 | 修改 CMakeLists.txt、更新依赖库或打包脚本 |
-
Body 与 Footer 规范（选填）
-
Body（详细描述）： 补充说明本次修改的动机、具体的底层实现逻辑，以及与修改前行为的对比。适合逻辑复杂的底层系统开发。 -
Footer（页脚）： 主要用于两种情况：-
不兼容变动 (BREAKING CHANGE)： 如果当前代码与上一版本不兼容（例如修改了核心 API 接口），必须在 Footer 处标明，并说明迁移方法。
-
关闭 Issue： 例如
Closes #123, Closes #124。
-
-
-
一些示例
示例1：新增核心功能
feat(scheduler): implement PendSV context switching mechanism示例2：基于设计原则的代码重构（包含 Body）
refactor(sensor): decouple SCD41 and SHT30 logic from main loop Apply Dependency Inversion Principle to separate hardware- specific reading logic from the central data hub. This makes adding new I2C sensors in the future plug-and-play.示例3：构建工具调整
chore(build): update CMake to output all binaries to bin directory示例4：破坏性更新 (Breaking Change)
feat(api): redesign the sensor module registration interface BREAKING CHANGE: The `register_sensor()` function now requires a priority argument. Existing device drivers must be updated to pass the new parameter.
4.3. 管理已提交的更改
使用 rebase 命令管理已提交的更改。
git rebase -i HEAD~n`n 是你想回顾的最近几次提交数，它会打开一个类似文本编辑器的界面。like this:
pick 111111 fiix: 拼写错误的提交说明
pick 222222 fix: 修复了中断问题
pick 333333 feat: 最新的功能
# Rebase ... (下面是一大堆注释说明)注意，这里的顺序和
git log是相反的。最上面的是最旧的提交，最下面的是最新的。
找到你想修改的记录，更改开头的指令，常用的指令：
-
pick(保留)： 什么都不做，保留该提交 -
Squash（合并）： 把几个零碎提交，合并到前一个提交 -
Reword（改写）： 修改某次提交的描述信息（Commit Message） -
Drop（删除）： 删除提交记录
这是一个重写提交描述的例子：
- 编辑指令
reword 111111 fiix: 拼写错误的提交说明
reword 222222 fix: 修复了中断问题
pick 333333 feat: 最新的功能
# Rebase ... (下面是一大堆注释说明)-
编辑好后，保存并退出当前编辑器
-
上一个编辑器关掉，Git 会立刻为你打开第二个编辑界面。这个界面是你要修改的那个提交的提交描述。
-
修改提交描述完成后，保存并退出当前编辑器
-
Git 会为你打开下一个你想要修改的提交的提交描述编辑界面
-
重复步骤4，直到你想修改的所有提交记录全部修改完成
这是一个合并提交的例子：
-
编辑指令
pick 111111 fiix: 拼写错误的提交说明 squash 222222 fix: 修复了中断问题 squash 333333 feat: 最新的功能 # Rebase ... (下面是一大堆注释说明) -
编辑好后，保存并退出当前编辑器
（如果有冲突，处理冲突）
- 上一个编辑器关掉，Git 会立刻为你打开第二个编辑界面。这个界面要求你为合并提交写一个新的提交描述
（此时如果意识到自己合并错了，想要放弃合并，新开一个终端，运行 git rebase --abort 命令）
-
编辑好后，保存并退出当前编辑器
-
最终结果：提交记录
222222和333333消失，所有修改都并入了111111。
（如果想要撤回已合并的提交，请使用 git reflog + git reset --hard HEAD@{n} 或 git reset --hard <hash> ）
5. 分支的管理
5.1. 切换分支
git checkout <分支名>5.2. 重命名当前分支
git branch -m <name>6. 版本管理
6.1. 查看历史版本
git log --oneline 6.2. 回退版本
-
回退，同时删除提交记录
git reset --soft HEAD^ #回退到上一个版本 git reset --mixed HEAD~n #回退到前n个版本 git reset --hard <hash> #使用hash值指定版本--soft：回退掉的那些版本的修改全部都会保留在“暂存区”（Staging Area）中。你可以重新修改并再次 commit。--mixed：修改会保留在“工作区”（Working Directory）中，表现为未暂存的文件。--hard：非必要不要使用！ 将项目完全恢复到某个版本提交时的状态，之后所有的更改全部丢弃，且无法找回。执行前请务必确认并理解后果。建议执行前先使用git stash
禁止在多人协作中使用
git reset回退版本！除非完全理解后果
-
重新提交一个记录，用于撤销某版本的更改
git revert <hash>A->B->C->D->E->(F)HEAD 想回退到C版本，即撤销D版本的修改。 git revert D A->B->C->D->E->F->(D')HEAD D'撤销了D所做的所有更改 因为是直接撤销D的改动，如果E、F版本依赖或覆盖了D的代码，则需要解决来自E、F的版本冲突，才能成功提交 D‘