git使用笔记:git日常工作流和命名规范

📘 目录(点击可跳转)

  • 使用流程
    • [0 从远程已有仓库开始](#0 从远程已有仓库开始)
    • [1 初始化流程](#1 初始化流程)
    • [2 标准功能开发流程](#2 标准功能开发流程)
  • 规范
  • 进阶操作
    • [1 查找提交历史](#1 查找提交历史)
    • [2 从某个历史版本创建新分支](#2 从某个历史版本创建新分支)
    • [3 恢复某个文件到指定版本](#3 恢复某个文件到指定版本)
    • [4 撤销某次提交 revert](#4 撤销某次提交 revert)
    • [5 强制回退到某个版本 reset-hard](#5 强制回退到某个版本 reset-hard)
    • [6 查看某个版本的文件内容](#6 查看某个版本的文件内容)
    • [7 对比版本差异](#7 对比版本差异)
  • 问题解决
    • [CRLF 报错解析与解决](#CRLF 报错解析与解决)

使用流程

0. 从远程已有仓库开始(只需一次)

场景:GitHub 上已经有仓库了,本地还没有代码。

目标 命令示例 注释
1. 克隆远程仓库 git clone <your-repo-url> 如:git clone https://github.com/123awsd/smart_watch.git
2. 进入项目目录 cd smart_watch 进入刚克隆下来的项目文件夹。
3. 检查远程是否正常 git remote -v 确认 origin 显示正常即可。
1.初始化流程(仅需一次)
目标 Windows (Git Bash) 命令 注释
1. 终端进入项目 cd /path/to/your/project (或右键 → \rightarrow → Git Bash Here) 确保终端路径正确。
2. 初始化仓库 git init 在当前目录创建 .git 文件夹。
3. 创建忽略文件 touch .gitignore 创建忽略文件。
4. 暂存 .gitignore git add .gitignore 仅暂存忽略文件。
5. 首次 Commit git commit -m "chore: Init repository structure" 使用 chore 类型。
6. 关联远程仓库 git remote add origin <your-repo-url> 绑定您的远程仓库 URL。
7. 推送主分支 git push -u origin master 首次使用 -u 建立跟踪关系。
2.标准功能开发流程
步骤 Git Bash 命令 关键原则与注释
1. 准备 git checkout master \newline git pull origin master 在切分支前,确保本地 master 分支与远程同步。
2. 创建功能分支 git checkout -b feature/temperature-sensor 口诀: 动手前,先分支。
3. 编码与提交 git add src/sensors/temp.c \newline git commit -m "feat: 添加温度传感器驱动" 在功能分支上进行多次原子化提交。
4. 合并功能 git checkout master \newline git merge feature/temperature-sensor --no-ff -m "feat: 实现温度传感器功能 v1.1" --no-ff 关键:保留分支历史,专业且易回溯。
5. 清理分支 git branch -d feature/temperature-sensor \newline git push origin master 口诀: 合并即删除。
6. 版本标记 (Tag) git tag -a v1.1.0 -m "Release v1.1.0" \newline git push origin --tags 重要: 标记稳定版本,并推送标签到远程。

规范

分支命名规范
前缀 用途 示例分支名
feature 新功能开发 feature/laser-power-system
fix 一般 Bug 修复 fix/oled-init-bug
hotfix 紧急线上 Bug hotfix/watch-crash-on-low-battery
refactor 重构 refactor/motor-control-module
chore 项目维护、脚手架 chore/update-build-scripts
experiment 实验性质、不一定合并 experiment/new-tracking-algorithm
prototype 快速 PoC / Demo prototype/laser-gimbal-poc
提交信息规范
type 说明 典型场景(嵌入式) 示例
feat 新功能 新增传感器、协议、控制算法、菜单页面 feat: add temperature sensor driver
fix 修 Bug 修崩溃、逻辑错误、边界条件、初始化问题 fix: prevent null ptr in adc init
refactor 重构 调整结构、拆分文件、提取公共函数,不改变对外行为 refactor: extract i2c helper functions
docs 文档 README、接线图说明、注释增强 docs: add setup guide for dev board
chore 杂项维护 工程配置、依赖更新、.gitignore、重命名文件等 chore: update keil project settings
test 测试 自检程序、单元测试、硬件回归测试 test: add imu calibration test script
perf 性能优化 提升刷新率、减少延迟、降低功耗 perf: reduce i2c reads in main loop

.gitignore 内容

(嵌入式专用)

Code 复制代码
# 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配置文件和日志
*.log
.vscode/
.idea/

进阶操作

1. 查找提交历史(获取版本号)

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

Bash 复制代码
git log --oneline --graph

📌 示例: 记录哈希值,如:a1b2c3d

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

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

Bash 复制代码
git checkout -b new-branch-name a1b2c3d
  • 示例:

    Bash 复制代码
    git checkout -b fix/old-bug a1b2c3d
3. 恢复某个文件到指定版本(安全,不影响其他文件)

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

  1. 恢复文件:

    Bash 复制代码
    git checkout a1b2c3d -- path/to/file.c
  2. 暂存并提交:

    Bash 复制代码
    git add path/to/file.c
    git commit -m "fix: restore file.c from a1b2c3d"
4. 撤销某次提交(生成"反向提交",安全可逆)

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

Bash 复制代码
git revert a1b2c3d
  • Git 会自动生成一条提交信息,类似:

    Makefile 复制代码
    Revert "<原提交信息>"
5. 强制回退到某个版本(危险,需谨慎)

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

  1. 本地强制回退:

    Bash 复制代码
    git reset --hard a1b2c3d
  2. 如果远程也要一起回退(非常危险):

    Bash 复制代码
    git push -f origin master

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

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

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

Bash 复制代码
git show a1b2c3d:path/to/file.c
7. 对比两个版本的差异
  • 对比两个指定的版本:

    Bash 复制代码
    git diff a1b2c3d b3c4d5e
  • 对比当前工作区与指定旧版本的差异:

    Bash 复制代码
    git diff a1b2c3d
       ```

问题解决

报错和解决

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

相关推荐
degen_1 小时前
编写其他UEFI application:读取CPUID
c语言·笔记·bios
漏洞文库-Web安全1 小时前
CTFHub 信息泄露通关笔记9:Git泄露 Index - 指南
笔记·git·安全·web安全·elasticsearch·网络安全·ctf
重生之我在番茄自学网安拯救世界1 小时前
网络安全中级阶段学习笔记(六):网络安全 SSRF 漏洞学习笔记
笔记·学习·网络安全·ssrf
weixin_307779132 小时前
深度解析 Jenkins Git Client 6.4.0 插件:核心功能、应用场景与最佳实践
运维·git·架构·jenkins
moringlightyn2 小时前
Linux---基础IO(文件理解 文件接口使用 文件系统层面)
linux·运维·服务器·c语言·笔记·系统·文件
丝斯20112 小时前
AI学习笔记整理(29)—— 计算机视觉之人体姿态估计相关算法
人工智能·笔记·学习
liliangcsdn2 小时前
elasticsearch全文搜索索引结构示例
大数据·elasticsearch·搜索引擎
終不似少年遊*2 小时前
【Git使用】Git 团队开发常用命令汇总手册
git·团队开发·开发工具·使用手册·项目提交
未若君雅裁2 小时前
JVM实战总结笔记
java·jvm·笔记