掌握 Git 不仅仅是学会几个命令，而是建立一套'时光机管理哲学'。无论是单打独斗还是团队协作，一套好的 Git 实践能够让你在代码出 Bug、需求反复横跳、甚至队友乱写代码时，依然保持从容。
本文梳理了从基础日常到团队协作的 Git 最佳实践指南。
1. 基础工作流（日常开发正确姿势）
看似最简单的 pull -> add -> commit -> push，其实暗藏玄机。
git status（随时随地的'雷达'）：- 最佳实践： 敲任何改变状态的命令前，先敲一次
git status。确认当前在哪个分支、哪些文件被修改了。不要瞎猜。
- 最佳实践： 敲任何改变状态的命令前，先敲一次
git pull（同步代码）：- 最佳实践： 每天开工第一件事就是 Pull。
- 进阶用法： 推荐使用
git pull --rebase。如果你的本地有未提交的 commit，默认的 pull 会产生一个极其丑陋的自动 merge 节点。使用--rebase会把你的本地提交'优雅地'移到远端最新代码之上，保持历史一条直线。
git add（暂存变更）：- 避坑指南：极度不建议无脑使用
git add .。这极易把本地的测试配置、临时文件、或者没写完的脏代码一起搞进去。 - 最佳实践： 明确知道自己改了什么，可以指定文件
git add src/main.c；或者如果你一定要用git add .，请在此之前务必用git status扫一眼修改列表。
- 避坑指南：极度不建议无脑使用
git commit（存档点）：- 最佳实践：原子化提交（Atomic Commits）。一个 Commit 只做一件事。比如'修复登录页 UI'和'优化数据库查询'必须是两个独立的 Commit。这为将来排查 Bug 甚至是回滚（Revert）提供了极大便利。
git push（同步远端）：- 最佳实践： 下班前务必 push 到远端（即便功能没做完，也可以推到一个自己的草稿分支）。不要把电脑当成唯一的代码备份服务器。
2. Commit 规范（让历史记录说人话）
'修复 bug'、'update'、'aaa' —— 这种 Commit 过了三天你自己都不知道改了啥。团队协作中，强推 Conventional Commits（约定式提交）。
标准格式： <type>(<scope>): <subject>
常用 Type：
feat: 新功能 (Feature)fix: 修复 Bugdocs: 只改动了文档（Readme 等）style: 格式修改（不影响代码运行的变动，如空格、格式化）refactor: 代码重构（既不是新增功能，也不是修改 bug 的代码变动）test: 增加或修改测试chore: 构建过程或辅助工具的变动（如更新依赖包）
优秀示例：
feat(auth): 新增微信扫码登录功能
