Git 日常开发工作流与提交命名规范

规范

分支命名规范

提交信息规范

.gitignore 内容

嵌入式专用

# Keil/IAR 等工程文件 *.uvprojx binary *.uvoptx binary *.uvguix* binary # 目标文件 / 映像文件 (编译产物)
*.axf binary *.elf binary *.hex binary *.map binary # 二进制数据
*.bin binary # 编译中间文件
*.o binary *.d binary *.bak *.srec # 常见的 IDE 配置文件和日志
.vscode/ .idea/

进阶操作

1. 查找提交历史（获取版本号）

使用图形化、简洁的方式查看提交历史，并记录您想要操作的提交的 哈希值（hash）（通常取前 7 位）。

git log --oneline --graph 

📌 示例： 记录哈希值，如：a1b2c3d

2. 从某个历史版本创建新分支（最推荐的做法）

场景： 想基于旧版本重新开发，例如修复老 Bug 或进行实验性功能开发。

git checkout -b new-branch-name a1b2c3d 

示例：

git checkout -b fix/old-bug a1b2c3d 

3. 恢复某个文件到指定版本（安全，不影响其他文件）

场景： 某个文件被不小心改坏了，只想单独恢复它。

暂存并提交：

git add path/to/file.c
git commit -m "fix: restore file.c from a1b2c3d"

恢复文件：

git checkout a1b2c3d -- path/to/file.c 

4. 撤销某次提交（生成'反向提交'，安全可逆）

此操作会生成一个新的**'反向提交'来抵消原提交的更改。这是撤销已 push 到远程分支的提交的安全**方法。

git revert a1b2c3d 

Git 会自动生成一条提交信息，类似：

Revert "<原提交信息>"

5. 强制回退到某个版本（危险，需谨慎）

此操作会修改历史，不适用于多人协作项目。通常仅在本地分支出现无法挽救的混乱时使用。

如果远程也要一起回退（非常危险）：

git push -f origin master 

本地强制回退：

git reset --hard a1b2c3d 

⚠️ 风险提示：git reset --hard + git push -f = 重写历史。请确保您了解后果，且仓库只有您自己使用，或团队已明确同意。

6. 查看某个版本的文件内容（只看不改）

场景： 想确认旧版本某个文件是如何编写的，不需要恢复文件。

git show a1b2c3d:path/to/file.c 

7. 对比两个版本的差异

对比当前工作区与指定旧版本的差异：

git diff a1b2c3d

对比两个指定的版本：

git diff a1b2c3d b3c4d5e 

问题解决

CRLF 报错解析与解决

报错：

LF will be replaced by CRLF the next time Git touches it

原因：

你的项目中有很多文件是 LF 换行符（Linux 格式）， 但你当前的 Git 配置或 .gitattributes 规定这些文件在 checkout 时要变成 CR（Windows 格式）。因此 Git 在 add 时会提示：下次 Git 处理这些文件时，LF 将被自动替换为 CRLF。 也就是说：

• 文件内容不变
• 只是换行符从 \n 变成了 \r\n
• 非常常见，特别是 STM32 + Git 在 Windows 中开发

解决方法：

告诉 Git 不要自动转换换行符（最常用） 在项目根目录执行： git config core.autocrlf false