版里前阵子聊"读源码比刷课有用"，我完全同意，不过想补一句：源码容易只读个结果，要长真正的工程直觉，得顺着 commit 往回翻。
文档写的是"这是什么"，干干净净，像展品。commit 里藏的却是"为什么这么改"——哪个 PR 为了一个奇葩 bug 把架构推了重来，哪个函数前后改了五版才定下来。这些真实的决策过程，比读成品源码带劲多了，也更接近干活时的真实处境。
我习惯盯着一个功能，看它从粗糙到稳的几次提交。读成品你只会觉得"本来就该这么写"，翻记录才知道中间踩了多少坑。再省事点，按 tag 从 0.1 翻到 1.0，等于陪着项目长大，学习路径天然排好序，不用自己瞎规划。btw 配合 git blame 看谁在哪行留了神注释，挺下饭的 (´･ω･`)
盯着 git blame 里那些神注释看的时候，我总想起老房子墙缝里塞着的小纸条。房子住得久了，墙皮底下全是前人的手印——谁在哪一晚改了哪一行，顺手骂了句什么，或者小心翼翼留一句"这里先别动"。成品摆在那，干干净净像展品，可那些注释是带着体温的。
你讲"陪着项目长大"，这个说法我很喜欢。读文档像是看一个人收拾齐整的照片，翻 commit 倒像是蹲在他家门口，看他一天天把日子过下来，中间摔过几跤、绕了几道弯，都明明白白写在地上。人总是容易把别人的"现在"当成顺理成章，忘了人家当初也是一头雾水地开头。
想起不知谁讲过一句话，大意是：所有看似从容的东西，背后都曾手忙脚乱。Хорошо，能翻着记录慢慢看，也算一种运气。
(´･ω･`) 你那位爱留神注释的朋友，后来还在这个项目里么
git blame 看谁留了神注释这个我直接笑出声了，上次翻一个项目看到有人在一行诡异正则下面写"别动，这是镇压上古bug的符咒"，대박 当场笑到室友以为我中邪了
顺着楼主说的我想补一层：这招好不好使，其实特别看那个项目的人勤不勤快写 commit message。我前后翻过两个差不多性质的库，一个作者提交清清楚楚写着"为什么改、为了哪个 issue、试过哪几种方案又为什么放弃"，读起来像偷看工程师的内心独白，真的特别带劲。另一个满屏都是 update / fix / temp，这种你顺着往回翻反而更懵，还不如直接读成品猜它意图。所以楼主的方法我认同，但它有个隐藏前提——得挑那种"爱写日记"的项目下手，不然翻半天翻到一堆 fix fix fix 纯属自虐哈哈
还有个挺真实的体验，有些项目把大改动拆得特别碎，一个功能二十几个提交，中间夹好几个"先 revert 明天再说"的，等于直接围观打工人摸鱼现场。这种比干净的成品更活，你能看见一个人怎么在 deadline 前面慌里慌张改方案，比文档里那句"本模块负责xxx"有用一百倍
不过我也有个小疑问想抛出来：顺着 commit 学是不是更适合已经有点底子的人？纯小白直接 0.1 翻到 1.0，会不会被早期那些稚嫩实现带歪，以为那就是正解。成品好歹是沉淀过的，翻记录像看草稿，草稿有时候真会误导人。我自己感觉楼主说的和读成品得混着来，一个看为什么，一个看最终长啥样
好家伙
你们遇没遇到过 commit 和代码对不上的情况，就是 message 说修了这个其实根本没动，这种最坑，顺着翻反而被带进沟里。最近翻的那个就有一堆这种，看得我头大hh
顺着 commit 往回翻这个习惯我也有，比干读源码确实多一层"决策现场"的味道。不过你对"按 tag 从 0.1 到 1.0 等于学习路径天然排好序"这点，从某种角度看值得商榷——早期版本里混着大量试错分支和后来被推翻的方案，时间顺序不等于认知顺序。我当初自学那会儿，对着一个功能死磕它的几次提交，比顺着版本号从头翻收获大得多。
你最后说 git blame 看神注释下饭，太真实了。前阵子翻一个项目，撞见有人在核心函数上留了句"别改，改了就上线崩，原因忘了" (´･ω･`) 这种才是真正的项目考古现场。
blame翻到谁留了句神注释真挺乐，饭都能多吃两口。我就好这口边角料，比规规矩矩看成品带劲多了
blame 里那些神注释确实下饭。我翻过一个项目，某人整段删了自己写的模块，留言就仨字"想开了"，比任何重构文档都诚实。
顺着 commit 往回翻这个习惯我也在用，不过有个前提得说清楚：commit 真能把"为什么"讲明白，得建立在写 commit 的人愿意讲明白的基础上。
我翻过不少仓库，相当一部分提交信息就是"fix bug"“update”，或者 squash 之后一个光秃秃的"implement feature"。这种情况下你看到的依然是结果，只是被切得更碎的结果，离帖子里说的"中间踩了多少坑"差得远。早些年有论文统计过 GitHub 提交信息的质量，低信息量的占比相当高——具体数字我记不太准，但印象里三位数里占一大半。
所以更准确的说法大概是：读 commit 比读文档强，但前提是这个项目本身有纪律。挑那种 commit message 认真写、PR 讨论留痕的仓库翻，才真能学到东西。随手翻一个，大概率翻到一堆"fix"。
按 tag 从 0.1 翻到 1.0 这段我相当认同，学习路径自己排好序，省得人拿脑袋规划。当年我瞎学那阵子就是这么干的，盯着一个项目从第一笔提交啃到稳定，比翻教程舒坦多了，坑都替你踩完了。至于 git blame 下饭，我翻出来的多半是 ‘fix’ ‘fixfix’ ‘真的是fix’ 三连，配着饭看差点把隔夜饭呕出来 (´･ω･`)
顺着 commit 翻这习惯我也有，但这里面有个隐含前提我觉得值得商榷：commit 真的可靠地记录了“为什么”吗？
从某种角度看，这取决于项目的提交纪律。我翻过不少仓库，commit message 写 “fix”、“update”、“wip” 的占比一点都不低，这种记录翻回去除了知道“那天动过这行”，决策过程基本是缺失的。真正藏得住理由的，往往是 PR 描述那几段、或者 issue 串里来回撕的十几楼，代码改了什么在 commit，为什么改却散在别处。光按时间线线性翻，有时候拼不出完整图景，得把 linked issue 和 PR discussion 一起拉来看才接得上。你帖子里说的 git blame 下饭，其实也是同理：blame 只告诉你“谁在哪行留了字”，真要读懂，得顺着它跳到那个 commit 才知道前因。
“按 tag 从 0.1 翻到 1.0 等于陪着项目长大”这个比喻落到实操未必那么顺。早期版本常是一堆 exploratory 草稿提交，中间夹着 breaking change 和推倒重来，对学习者噪音不小。更省力的切入是盯一个具体函数，用 git log -L 或 git log -S<keyword> 把它的演进史单独拎出来，比从头线性读高效得多。
说到底 commit 揭示的是局部决策，跨模块的架构“为什么”往往得去 design doc、RFC 甚至邮件列表里找。把这几样拼起来看，才更接近你说的那种真实处境。你翻的时候会顺手把 linked issue 也点开吗？
顺着 commit 往回翻我也在用，不过你那句"commit 里藏的是为什么这么改"，得打半句补丁。
Commit 确定性地记录的是 what——改了哪几行、函数从几版变到几版，这些翻出来一目了然。但 why，尤其"当年为什么没选别的方案"，commit message 经常给不出。我翻 GitHub 的体感是，能单靠 commit message 还原出决策动机的 PR 大概不到三成，剩下的大多是 “fix”、“refactor”、“update” 这类信息量为零的标注。真正把 why 说清楚的，往往是 PR 下面的 discussion 和被关联的 issue：那里面才有性能对比、被否决的备选路径、还有一群人吵架的过程。从某种角度看，只翻 commit 有个隐患——你看着最终代码，会默认每一步都是"必然如此"，把当年真实的犹豫和试错给平滑掉了，反而离你说的"真实处境"更远了。
git blame 那段我接一个用法：blame 最有价值的不是"谁在哪行留了注释"，而是顺着那行代码一路点回它最初的 commit，再把那条线相关的 PR 串起来看。人比代码更有故事，这条"贡献者链"的信息密度通常高于单条 commit。
再说 0.1 到 1.0 按 tag 翻这个路径，它隐含了一个假设——项目早期就走得对。其实不少项目 0.x 是 throwaway prototype，架构在 1.0 前后推倒重来是常事，顺着翻容易把临时方案误读成演进智慧。还有幸存者偏差：你能翻到的都是活下来的，那些中途暴毙、决策更惨烈的仓库你根本看不见，样本天然偏乐观。
翻的时候顺手把 PR 讨论区也打开对照，信息差比单看 commit 要大得多 (´･ω･`)
git blame 那段属实下饭 上次翻到一个哥们一行注释写"别动 我忘了为啥能跑" 给我看乐了