git 鼓励频繁提交commit early, commit often，用好分支，多用分支
代码本身很多逻辑是深度耦合的，一个调试/试错可能要改动很多个地方，一不小心污染到无法恢复。所以版本管理要随时回退，并且要做到小颗粒度回退，原子级别回退。
对于代码来说，因为是文本+增量存储(差异存储)+diff算法，使得Git 的存储非常高效，频繁commit和创建分支，存储的开销简直是微不足道，完全是零成本，无负担！所以请尽情commit，尽情分支。
最佳实践：如何更好地 commit？
- 保持单一职责（One Change Per Commit）
每个 commit 只做一件事，避免“大杂烩”式提交。若把几十个修改一次堆到代码里，无论是别人还是自己都很难看出到底要改多少相关地方，哪个先改，哪个后改，为啥不能那么改，为啥必须这么改。 - 编写清晰的提交信息
提交信息应该简洁、明确，遵循 “标题+正文” 格式。
好处：
- 每个独立的小改动拆分为单独的 commit，有助于保持代码的清晰性。更容易看懂代码的逻辑、思路及推演过程。便于溯源和分析代码历史。
- 便于排除问题，便于回滚。
分支管理：
即使是一个人开发的项目，如果是功能简单的小项目，可以一直直接在dev分支开发，简单直观。如果是功能多、模块多、长期开发的项目，也建议每个功能都独立一个 feature 分支上开发。特别是维护多个版本的项目，以及要同步开发多个功能时（一个功能未完全做完，又要应对另一个需求的开发）。
分支管理的个人开发最佳实践：
1. 如果项目较简单或初期开发，直接在 dev 分支开发即可：
- 快速迭代，减少操作步骤；
- 适用于独立开发、小项目或 MVP 阶段。
2. 如果项目日益复杂或长期维护，建议使用功能分支模式：
- 任何独立、重要的特性或修复，单独创建
feature/xxx分支； - 适合需要频繁切换任务、进行实验、维护多个版本的场景。
分支的删除：删除已合并并且不再需要的分支是一个好的实践。
每个独立功能、修复开一个分支
遵循分支命名规范
便于团队协作，提高代码审查效率
Git Commit 提交规范 笔记——Git Commit 提交规范_git提交规范-CSDN博客
https://www.conventionalcommits.org/zh-hans/v1.0.0/
HEAD是指向当前工作目录的指针。
当前分支（Current Branch） --当 HEAD 指向一个分支的最新提交时，该分支就是当前分支。当 HEAD 处于游离（Detached HEAD）状态时，就没有“当前分支”这一说法了。
撤销/还原/重置
| 特性 | Undo Commit 撤销最近一次 | Revert Commit 还原到<hash> | Reset Commit 重置到<hash> |
|---|---|---|---|
| 操作类型 | 撤销最近的提交 | 创建一个新的提交来撤销指定提交的更改 | 重置分支的历史，回退到某个提交的状态 |
| 影响提交历史 | 会撤销最后一次提交，不改变历史 | 不改变历史，创建新的撤销提交 | 会修改提交历史，删除或移动提交 |
| 是否修改工作目录 | 保留工作目录和暂存区的修改 | 保留工作目录的更改，创建新的撤销提交 | 可能会丢弃工作目录和暂存区的更改（取决于模式） |
| 适用场景 | 本地开发过程中撤销最近的提交 | 撤销某个提交，但保持历史不变，适用于公共分支 | 重写本地历史，撤销不需要的提交，适用于私有分支 |
| 是否创建新提交 | 不会创建新提交，直接撤销 | 会创建新的提交来撤销某次提交的更改 | 不会创建新提交，直接重置到指定的提交 |
| 适合的分支类型 | 本地分支（通常是暂时性撤销） | 公共分支（因为不会修改历史） | 本地分支，特别是私有分支 |
| 对团队协作影响 | 不会影响其他人，除非已经推送到远程仓库 | 不影响其他人，安全地撤销已推送的提交 | 可能会导致团队成员的提交历史不同步，若已推送需要谨慎使用 |