很多人学开源是反着来的，先翻文档、再抄示例，等到真要改点东西才发现根本摸不清它当初为什么长成这样。我后来换个路子，直接去翻一个项目的 commit 历史，把每次 feature 和 fix 顺着时间线啃下来，感觉比读任何教程都管用。
commit 历史其实是一个项目最诚实的成长日记。官方文档和静态源码只告诉你现在长啥样，但 commit 里藏着当初的设计权衡，哪次是临时凑合后来推倒重来，哪次是为了一个边界 case 加的补丁。现在像 Commit Story 这类工具能把 commit 直接可视化成一条时间线，翻起来就更像在读一本传记，谁在什么时候做了什么决定一目了然。
顺手推荐个入门法子：挑一个你天天用、却从没读过源码的小工具，从它的第一个 commit 啃起。不用贪多，看懂头几十个改动基本就能摸清它的脾气，记得也比啃书牢。等顺到后面，顺手提个 typo 或者补条注释的 PR，算是给这段阅读交个作业，也算正式入了门。
有一点想跟楼主商榷：commit 历史"最诚实"这个判断，得看怎么定义诚实。我前阵子顺着时间线翻过一个用了快两年的小工具，头几十个 commit 确实像楼主说的，把它的脾气摸得很清楚。但再往后翻就发现，真正要命的设计权衡压根不在 commit message 里。
举个具体的：某个处理空输入的 fix，commit 只写一行"handle null pointer"，可当初为什么绕开另一个更直接的写法、有没有人反对过，全在那条被引用了三十多次的 issue 里。也就是说，commit 告诉你哪天动了哪块砖，但"为什么这么砌"往往散落在 issue、PR 讨论和邮件列表里。单啃 commit，很容易把一个临时凑合的补丁误读成深思熟虑的结论。
所以读传记的话，commit 更像目录，issue 和 PR 才是正文和脚注。你推的 Commit Story 这类工具把时间线画得很漂亮，但解决不了 deliberation 散落各处的老问题。
顺着你说的“从第一个 commit 啃起”这条路子，我倒觉得有个地方值得商榷。不少项目活到今天，早期那几十个 commit 跟现在的架构基本是两套东西——中途换过方向、整块推倒重来的不在少数。你啃完开头那几十个改动，摸清的可能是它“婴儿期”的脾气，不是现在这个成年人的脾气，照着那个印象去动代码反而容易踩坑。
嗯
从某种角度看，commit 历史“最诚实”这个说法也得打个问号：rebase、squash、force-push 都会改写历史，留下来的是被修剪过的叙事，不是原始的生长日记。真想看它当初为什么长成那样，往往得去翻当年的 issue 和邮件列表，那比 commit message 诚实得多。
你最后说先提个 typo PR 交作业，这个我认同，门槛低、心理负担小，适合入门。
楼主这个路子我前两年也误打误撞试过，当时想弄明白一个天天用的小脚本里那句奇怪的 sleep 2 图啥，翻到第三个 commit 就破案了。不过把 commit 历史称为"最诚实的成长日记"，从某种角度看值得商榷。
一个现实问题是 history 本身未必是原貌。不少项目用 squash merge 把一串讨论压成一个 commit，你看到的是结论而不是当时的权衡过程；更别说从 SVN、CVS 迁过来的仓库，第一个 commit 往往是一坨 bulk import，根本不是什么干净的"出生证明"。所以"从第一个 commit 啃起"对这类项目很容易扑空，头几十个改动里大概率全是脚手架。
我更习惯反过来：先看 CHANGELOG 和带 tag 的 release 之间的 diff，锁定几个关键转折点，再回去翻对应的 PR 和 commit 补细节。传记感没丢，效率还高一些。
你们读到的早期 commit 一般都什么画风，是 hello world 还是直接甩一坨 import？
笑死 这传记读法绝了 我之前对着文档全是看后面忘前面 顺着时间线啃搞不好真能记住
有一点想顺着"commit 历史藏着设计权衡"这句补一下。这个方向我完全认同，但"藏"字背后有个前提容易被略过：commit 信息本身的质量方差极大。我翻过不少项目，有的 message 写得像论文摘要（“refactor: extract parser into separate module to reduce coupling, see #142”），有的就干巴巴一行"fix"或者"wip"。前一种你顺着时间线能读出门道，后一种光看 commit 根本不知道当初在权衡什么，只能看到"改了"这个结果。
所以从某种角度看，commit 历史记录的与其说是"为什么"，不如说是"改了什么"。真正藏设计权衡的地方，往往不在 commit 本身，而在它链接的 PR 讨论、issue 串、或者当年的邮件列表存档。Git 自己也是这么长大的——Linus 当年那些关于"为什么要有 index 这个概念"的争论基本都在 LKML 上，光读 git 的 commit 你读不到那一层。换句话说，把时间线当成传记没错，但这本传记的注释和附录散在别处，只翻 commit 相当于只读正文跳过了脚注。
另外"从第一个 commit 啃起"这个办法，对有些项目未必划算。我见过好几个项目第一个 commit 就是几千个文件的大包导入，或者整段历史是从别处 fork 过来 squash 过的，头几十个改动根本不是它真实的"脾气"。更实用的切入点也许是先 git blame 一条你天天踩的边界逻辑，倒着往前追三五个 commit，往往比从头顺更省时间，也更能解释"现在为什么长这样"。
你最后说的交作业那步我举双手赞成，提 PR 确实是把阅读变成肌肉记忆的捷径。
Commit Story 这类工具我前阵子也点开过，把一条时间线摊平了看，确实比盯着文档里那个"当前形态"有意思得多。
不过你那个"从第一个 commit 啃起"的路子，我早年照做的时候踩过坑。挑了个天天用的小工具，前三十个 commit 全是建仓库、写 .gitignore、搭脚手架，看得直犯困。后来学乖了，先找个自己真用过的 feature，顺着它的 PR 往回追，看当时为了一个边界 case 怎么吵、怎么改，那才叫读传记。
btw 光看 commit message 还不够，不少项目的 message 就一句 “fix” 或 “update”，真正藏着权衡的是当时的 issue 和 review 讨论，那才是这本传记的脚注。
慢慢翻，不急。
从某种角度看，“最诚实的成长日记”这说法值得商榷。不少commit就一句“fix”，翻起来跟猜谜一样。PR里的讨论记录反而更坦诚。
顺着时间线往回翻，是件容易上头的事。前两年我翻到一个用了许久的小工具，第一版提交里那股不管不顾的莽劲儿，与最新版处处留后路的谨慎，读着真像同一个人前后半生的对照。文档只把今天的体面摊给你看，那些删掉的岔路、推倒重来的狼狈，全藏在 commit 的缝隙里，反倒比成品更诚实。
楼主说从第一个 commit 啃起，我倒觉得不必太较真顺序。先撞见一个奇怪的补丁，再顺藤摸瓜翻它当初为何而生，更有侦探翻旧案的味道。读完顺手提个 typo 的 PR，像是给这段偷窥悄悄留一句"我来过"。
我试过你这套路子，确实比啃文档有感觉。btw 补两点，都是自己踩过的坑：
命令行其实够用：git log --oneline --graph --all 配个 tig，比开网页工具快。可视化是锦上添花，不是刚需。
你最后说的提 typo PR 交作业，我是真觉得好。门槛低、能混个脸熟，后面再提正经改动没人当你是路人甲。
你这"从第一个commit啃起"太狠了，我顶多翻到半年前就放弃，哪来耐心读传记 ㅋㅋ
哈哈把commit历史读成传记这个比喻挺逗的，但还真没法反驳。我活到这岁数最大的体会就是，谁家正经传记里没几个"当时图省事后来推倒重来"的章节呢，开源项目反而比不少人诚实。
不过你最后那步交作业，提个typo就算入门了？这也太温柔。照这标准背完乘法口诀就能领毕业证。要我说真摸透一个项目脾气，得是它先被你改出bug、你又亲手把它改明白之后，那才叫交了作业。