git 鼓励频繁提交commit early, commit often，用好分支，多用分支

代码本身很多逻辑是深度耦合的，一个调试/试错可能要改动很多个地方，一不小心污染到无法恢复。所以版本管理要随时回退，并且要做到小颗粒度回退，原子级别回退。

对于代码来说，因为是文本+增量存储(差异存储)+diff算法，使得Git 的存储非常高效，频繁commit和创建分支，存储的开销简直是微不足道，完全是零成本，无负担！所以请尽情commit，尽情分支。

最佳实践：如何更好地 commit？

1. 保持单一职责（One Change Per Commit）
   每个 commit 只做一件事，避免“大杂烩”式提交。若把几十个修改一次堆到代码里，无论是别人还是自己都很难看出到底要改多少相关地方，哪个先改，哪个后改，为啥不能那么改，为啥必须这么改。
2. 编写清晰的提交信息
   提交信息应该简洁、明确，遵循 “标题+正文” 格式。

好处：

• 每个独立的小改动拆分为单独的 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）状态时，就没有“当前分支”这一说法了。

撤销/还原/重置