工程与协作
提交Commit
你可能会问
提交到底是什么？和「保存文件」差在哪？
简单来说
把一组相关代码变化保存为带说明的版本节点。
一天一大包一步一提交同样的一天，两种历史
回退 · 整包端走回退 · 精准摘除拆得清，才退得回
01 · 先这样理解
把抽象概念放进真实场景
把一组相关代码变化保存为带说明的版本节点。
换个角度想Commit 像日记本上的一篇日记：写清楚今天做了什么，落款日期。回头翻，每一天都找得到；只在草稿纸上涂改，过后什么都对不上。
02 · 点击演示
一天的修改，怎么提交才不给自己埋雷？
突出显示的部分，就是当前概念在整条流程中负责的位置。
- 一天攒到晚上全提
范围20 个文件内容登录 + 支付 + 样式混在一起只挑这一步相关的范围3 个文件内容只有登录相关 说明：「更新」
改了什么？说明里看不出来
说明：「修复登录超时」
一句话，讲清一件事
- 历史长这样
今天「更新」· 巨大一包前天「更新」· 又一包历史长这样#c3d4「修复登录超时」#e5f6「支付页样式微调」 - 牵一发动全身想撤支付改动，登录和样式跟着陪葬混装的历史，退无可退精准回退只撤支付那笔，其他毫发无损一个提交一件事，历史才有用
1 / 4
Stage · 挑出这次要提交的修改
03 · 放进真实任务
什么时候会遇到它
一步一存档
每完成一小步就提交，AI 改砸了最多损失一小步。
说明就是线索
排查问题时，提交说明帮你快速圈定嫌疑改动。
干净的历史
一个提交只干一件事，回退时不会牵连别的功能。
04 · 想一想
用一个问题检查理解
干了一整天，晚上把 20 个文件的修改一次性提交，说明写「更新」。这样有什么问题？
查看答案
这个提交混了一天里的所有改动：想撤销其中一个功能就得整包回退；「更新」两个字也提供不了任何线索。应该按任务拆开、及时提交，每个说明讲清这笔改了什么。
最容易踩的坑
提交说明是写给未来的自己看的。「fix」「更新」这种说明，三天后连你自己都不知道它改了什么。