跳转到内容
mCourse

协作级 Git 习惯

你将学会什么

Section titled “你将学会什么”
  • 把功能、修复、文档修改分开提交
  • 让每个提交保持独立、可回滚
  • 在合并前用一次 diff 检查代替反复返工

正文

Section titled “正文”

如果你已经会用 Git，下一步要建立“协作级提交习惯”。真正有价值的不只是 commit 能成功，而是别人看了提交历史就能理解变化原因。建议在课程项目和实习中持续强化这些最小习惯：

  • 功能、修复、文档修改分开提交
  • 每个提交保持独立、可回滚
  • 提交信息说明“为什么改”，而不是只写“改了文件”
Terminal window
# 不太可读：只说了“改了”，没说为什么
git commit -m "update report.py"


# 更可读：类型 + 变更内容，别人能直接理解
git commit -m "feat: 支持实验报告模板导出"
git commit -m "fix: 修复空模板导出时报错"
git commit -m "docs: 补充本地运行说明"

分开提交让每一条历史都小而可解释：以后回滚时，你可以只回滚“出问题的那一次修改”，而不是把一整段开发过程一起退回。

如果项目开始有队友参与，你只需要再加一条：在合并前先看一次 diff。这个动作能提前发现“改了不该改的文件”和“把调试代码也提交了”这类问题，避免大量后续返工。

动手练

Section titled “动手练”

知识检查

Section titled “知识检查”

先自己回答，再看答案：

  1. 为什么功能、修复和文档修改要分开提交？
  2. 提交信息应该说明“改了什么”还是“为什么改”？
  3. 合并队友分支前看一次 diff，主要能发现什么问题？
参考答案
  1. 分开提交让每条历史小而独立，评审、回滚和定位问题都更容易。
  2. “为什么改”，因为文件内容本身已经说明了“改了什么”。
  3. 改了不该改的文件、混入了调试代码等无关变更。

本节小结

Section titled “本节小结”
  • 提交按类型分开：feat:、fix:、docs:、chore:
  • 每条提交独立、可回滚，历史才值得信赖
  • 合并前先看一次 diff，是最便宜的代码审查
协作级提交小测
x
1 / 3

功能、修复、文档修改应该怎样提交？