编程与软件工程stevelosh.com
Git 公案
Git koans
2013 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
《Git koans》以禅宗公案的形式，用一则则幽默短篇揭示 Git 命令行界面中不一致、反直觉的设计——比如同一个概念在不同命令里有不同语法，初学者常常被搞得一头雾水。文章在 2013、2015、2017、2020 年多次登上 Hacker News 首页，成为讨论 Git 易用性的经典之作。
为什么经久不衰：它用轻松的寓言精准戳中 Git CLI 的历史包袱与概念混乱，多年后仍是理解'为什么 Git 难学、该怎样真正学会它'的最佳入门读物之一。
HN 评论精选
Git CLI 不一致不是大问题，理解其底层概念后自然豁然开朗，就像学 Unix 一样。
Git 的命令确实不一致，这是它有机生长、加上维护者高度重视向后兼容的结果。但用了多年后我并不在意。Git 在概念上其实很直白，只是很难从它巴洛克式的 CLI 中看出这些概念，所以靠内置帮助或 man 页学 Git 基本是浪费时间。要么读 Pro Git 这本书，要么直接看底层实现，之后不一致的 CLI 就不再是问题。如果这真是大问题，早该有人做出一个流行的新高层命令行工具了，但并没有。这和 Unix 很像：awk 的知识帮不了 sed，wget 和 curl 也不同，但当你理解了管道、正则、文件描述符等概念后，接口是否严格一致就没那么重要了。我同时开始用 git 和 hg，最后更喜欢 git——Mercurial 的 CLI 更好，但 git 更能做我想做的事。
js2查看英文原文
Git commands are not consistent. This is a result of it growing organically, and having a maintainer who strongly values backwards compatibility. But you know, having used git for years that doesn't bother me. Let me explain. Git is conceptually straightforward[1]. It is difficult if not impossible to discern those concepts from its baroque CLI. So learning git from its built-in help and/or man pages is suboptimal if not a complete waste of time. Either read the Pro Git book[2] or pop the hood[3]. Then the inconsistent CLI is no longer a big deal. If it were, someone would have come up with a new porcelain (high-level CLI) that would have taken hold by now. And no one really has. There is Easy Git[4] but I don't know anyone who uses it. And really, I see git as not much different than Unix in this regard. Unix commands vary widely in their usage. Does knowing awk help with sed? cpio and tar? wget vs curl? Eventually you understand concepts such as pipes, regular expressions, file descriptors, etc and you become familiar with the commands where you are able to apply these concepts, at which point does strict interface consistency between them matter? I dunno, but I started with both git and hg around the same time and ended up happier with git. Mercurial had the "better" CLI, but I found git was better at doing what I wanted. Before that I used clearcase, which has a very consistent CLI and yet I was constantly cursing at it. Or maybe I just have stockholm syndrome and I'd feel differently if I'd ever used plan 9. :) 1. http://tom.preston-werner.com/2009/05/19/the-git-parable.html 2. http://git-scm.com/book 3. http://newartisans.com/2008/04/git-from-the-bottom-up/ 4. http://people.gnome.org/~newren/eg/
复述文中一则公案：'patience' 既是禅语也是真实的 git 合并策略参数。
一位 Git 大师和一个 API 新手站在拥挤的办公室里。'我在合并两个巨大的 XML 文件，总是遇到大量烦人的冲突。你一定有让行匹配得更易读的策略，我最好的选择是什么？'大师说：'耐心。'新手抗议：'我已经手动解决好几个小时了！我的合并工具应该能推断上下文、正确匹配行啊！'大师叹气离开房间。几小时后回来，办公室空无一人，只剩新手在显示器前低头认输。'git merge --strategy-option=patience，'大师低声说。新手在明确的语境中听到同一个词，顿悟了。
etjossem查看英文原文
Context --- Master Git and a novice API developer stood together in a crowded office. "I am trying to merge two massive XML files," explained the API developer, "and I am getting many tedious conflicts. You must have a strategy for making the lines match up in a human-readable manner. What is my best option?" "Patience," said Master Git, turning away from the monitor. "But I have been manually resolving for hours!" protested the API developer. "My mergetool ought to be able to imply context and match lines properly!" Master Git sighed and left the room without a word. Hours later, he returned to find the office empty and silent. Only the API developer remained, his head bowed in defeat before the monitor. "git merge --strategy-option=patience," whispered Master Git. Upon hearing the same word in explicit context, the novice was enlightened.
指出文中一则公案反映的其实是 Git 数据模型的基本事实：提交不属于分支，分支只是指针。
'唯有诸神'那一则让我觉得奇怪，也许是我对 Git 理解不够，但那似乎只是没搞懂分支是什么。一个提交并不是'在'某个分支上，它只是一个带有父 SHA 的 SHA 哈希；分支不过是指向某个 SHA 的指针。所以无法知道一个提交最初'来自'哪个分支，只能知道哪些分支目前包含它。合并两个分支后，当然无法从历史看出提交源自哪个分支——这个信息从一开始就不在历史里。不过在合并时以某种方式追踪这一点或许有用。
kevingadd查看英文原文
The 'Only the Gods' one seems weird to me; maybe I just don't understand Git well enough, but it seems like that one's just a case of failing to understand what a branch is. A particular commit isn't made 'on' a branch, so to speak; it's just a SHA hash that has a particular SHA as a parent. And then a branch is a pointer to a particular SHA. So there's no way to know which branch a commit originated 'on', merely which branches happen to contain a commit at present (because their current commit has the desired commit in its history). So, if you merge two branches together, of course you can not tell which branch a given commit originated on just by looking at history. That information was never in the history in the first place. I could see it being useful to track this in the merge somehow, though.
认为 CLI 不一致只是小问题，Git 更深的缺陷在于撤销合并困难和缺少规范的根提交。
遗憾的是，Git 在基本操作上不一致而巴洛克式的 CLI 还是它最小的问题——学习它只是如今每个开发者都要付的一次性沉没成本。更麻烦的是 Git 做不好一些非常基本的事情，比如合并分支：合并可以，但想撤销它、或让 Git 智能处理非线性历史，就祝你好运了。另一个有趣之处是每个 Git 仓库生来就带一个差一错误：没有规范的第一个'根'提交。这导致常见脚本写法在首个提交上会失效，而且任意仓库之间没有共同的根提交，使得事后把多个仓库合并成一个之类的事情变得更复杂。
patrec查看英文原文
Sadly the inconsistent and baroque command line interface of git for basic stuff is the least of its problems -- learning it is just a one time sunk cost every developer has to pay these days. What's more troubling is that git can't do some very basic stuff well, like merging branches. I mean you can do the merge, but good luck trying to revert it[+] or trying to get git to deal intelligently with non-linear history in general. Another fun thing is that every git repo starts its life with an off-by-one error: there is no canonical (and identical) first "root" commit, a NIL commit if you will. This is unfortunate for two reasons: 1. A lot of common scripting idioms will break on the first actual commit (e.g. finding changed files via git diff --name-only A A^ will not work if A is the first commit; yes it's possible to work around that, just like you can write shell scripts that deal with filenames with spaces). Also, it would be convenient in many cases to have an canonical initial empty NIL commit as symbolic reference, similar to how having HEAD is handy. 2. More subtle: the fact that there is no common shared root commit between arbitrary repos makes a couple of things more involved and confusing than they would otherwise be, for example rewriting several different repos into one after the fact. In theory it would be possible to work around that by everyone agreeing on a canonical first commit to start each repo with, but in practice that's of course unlikely to happen. Lastly, and not entirely unrelated: many, but no good solutions for sub-repositories. [+] https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt
指出 Git 官方后来新增 git switch 命令，正是对文中批评的回应。
最近有人告诉我，从 2.23 版本起 git switch 可以用来切换分支，它的出现正是为了解决 checkout 一次做太多事情的问题。
amingilani查看英文原文
I was recently told by someone that since 2.23 `git switch` lets you switch branches. It was made to address the fact that `checkout` does too many things. Here: https://git-scm.com/docs/git-switch
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选