掌握 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): 新增微信扫码登录功能


