在日常开发中，代码的每一次改动都可能影响最终结果。特别是在团队协作时，谁能改了什么、什么时候改的，这些信息显得格外重要。Git 作为最常用的版本控制工具，天然支持记录每次提交的修改痕迹，但很多人只停留在 git commit 和 git push 的层面，忽略了背后强大的追踪能力。
为什么需要关注提交记录的修改痕迹
想象一下，你正在修复一个线上 Bug，翻看代码发现某段逻辑被悄悄改掉了，但没人提过这事儿。这时候，翻提交记录就成了唯一线索。通过查看修改痕迹，你能知道是谁动的代码、改了哪些文件、具体增删了哪些行，甚至能还原当时的思考过程——前提是提交信息写得清楚。
用 git log 查看基本提交记录
最基本的命令是 git log，它会列出最近的提交历史：
git log每条记录包含提交哈希、作者、日期和提交信息。如果只想看简洁列表，可以加上 --oneline 参数：
git log --oneline查看具体的文件改动内容
光看提交信息还不够，关键是要看到“改了什么”。使用 git show 可以展示某次提交的具体变更：
git show <commit-hash>输出会显示该提交中所有文件的差异，比如哪一行被删除（前面带 -），哪一行被添加（前面带 +）。这种细粒度的追踪，对排查问题非常有用。
比较两个提交之间的差异
有时候你需要对比两个版本之间的变化，比如从昨天到今天的改动。可以用 git diff 指定两个提交：
git diff <commit1>..<commit2>这在做版本发布前的审查时特别实用，能快速定位所有变动点。
谁动了这一行？git blame 来帮忙
当你盯着某一行代码发愣，怀疑它是不是有问题时，git blame 能告诉你这行最后一次是谁改的：
git blame <filename>每一行前面都会显示对应的提交哈希、作者和修改时间。虽然名字叫“blame”，但别真去问责，更多是用于联系责任人或查看上下文。
提交记录也能被修改？小心使用
有时候提交信息写错了，或者不小心提交了敏感信息，就需要修改提交记录。Git 允许你通过 git commit --amend 修改最近一次提交：
git commit --amend -m "新的提交信息"如果是已经推送到远程的提交，再修改就得用 git rebase 或强制推送（git push --force），但这会影响团队成员，务必谨慎操作。
保留修改痕迹是一种职业习惯
好的提交习惯不是为了应付检查，而是为了未来的自己。每次提交都尽量写清楚“为什么改”，而不是“改了什么”。比如写“修复用户登录超时跳转错误”比“update login logic”要有价值得多。这些细节会在几个月后成为你最可靠的回忆录。
提交记录不是冷冰冰的日志，它是代码演进的足迹。看得懂痕迹，才回得了来路。