编程与软件工程eagain.net编辑精选
写给计算机科学家的 Git（2010）
Git for Computer Scientists (2010)
2010 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 2010 年的文章从计算机科学的角度解释 Git，重点讲清 Git 的底层数据模型，包括提交图、对象与引用等概念，而不是命令速查。它帮助读者建立 Git 内部机制的心智模型，从而理解日常操作背后的原理。
为什么经久不衰：Git 的底层模型多年未变，理解图与对象比背命令更能解释复杂操作，所以这篇概念性文章反复被推荐。
HN 评论精选
推荐补充 Pro Git 第9章以了解实现细节和内容寻址原语。
这是一篇很好的文章，时不时会被提到，很好地覆盖了底层理论。我会补充 Pro Git 第9章，它更侧重实际实现，并演示如何用 Git 的内容寻址原语从零创建提交。
keyist查看英文原文
This is a great post that gets mentioned from time to time and covers the underlying theory well. I'd supplement it with Chapter 9 of the Pro Git book: http://progit.org/book/ch9-0.html , which focuses more on the actual implementation and shows how to create commits from scratch using Git's content-addressable primitives.
推荐另一篇概念性 Git 入门文章。
我看过的最好的 Git 解释是《Understanding Git Conceptually》。
javert查看英文原文
The best Git explanation I've seen is "Understanding Git Conceptually" [1]. [1] http://www.eecs.harvard.edu/~cduan/technical/git/
Git 假定集中守门人的工作流，不适合人人自管代码的研究团队。
我做了20年计算机科学项目，从无源码管理到 CMS、SVN，再因学生想学新东西而改用 git。我们不断开会教 git、讨论最佳用法和处理常见问题，生产力反而下降；我通常只想把代码签入以防丢失，却被迫处理与自己无关的 git 问题，后来只好自己备份、偶尔签入。主要问题是 git 不符合我们的工作方式：它假设有一个守门人决定什么进入源码并做集成测试，而研究团队通常人人自己负责代码、测试和集成。
rapjr9查看英文原文
I worked on computer science projects for 20 years. At first we had no source management, everyone did whatever they wanted. Then we used CMS, and we occasionally stepped on each others toes but things were better. Then we switched to SVN and nothing much changed except we established a way to hold locks on files while they were being changed. Then we switched to git because the students wanted to learn the cool thing. We started having meetings to teach people git. Meetings about the best way to use git. Meetings to deal with common problems in our use of git. Productivity dropped because everyone now had to deal with git problems. It made my life hell because usually I just wanted to check in my code so it would not get lost, but instead I would continually get forced into reconciling git issues. I would have to resolve issues to get my code checked in because other people had changed something entirely unrelated to my work. I stopped using git and kept my own backups and only checked in code very occasionally so I could get work done. I noticed other people doing the same thing. The main problem I had with using git is it did not match the way we worked. Git assumes there is one person who is the gatekeeper, who decides what gets into the source, and who does some integration and testing. In research there usually is no one in charge of that, instead everyone is responsible for their own code, testing it, and integrating it. The git model was wrong for us, we never used pull requests at all, because there was no one person who understood everything well enough to approve them. Students don't have the experience or time to be the integrator, the profs don't even write code, and I had multiple other things that I had to do. So using git made a mess of what had been a simple process previously. Git was designed by Linus to make his life easier in managing changes to a kernel. It does not work well in other scenarios and should not be used in many circumstances. Yes, you can make it work, but at a cost.
Git 概念优雅但命令层混乱，需要面向实际用户和管理者的解释。
概念上 git 简单优雅，但 porcelain 层不自洽且充满特例，这让它很难向企业和开发者推销，他们难以理解版本控制是一个流程，而不是一个按钮。像《Git for CS》这样的文章很好，但我更想看到《给初级 Windows 开发者的 Git》《给老板的 Git》之类的文章。
politician查看英文原文
Conceptually, git is simple and elegant. The porcelain, however, is incoherent and riddled with special cases. This makes it a hard sell to businesses and developers who struggle to understand that version control is a process, not a button. So, articles like "Git for CS" are great and all, I guess, but what I'd really like to see is an article on "Git for junior Windows developers" or "Git for Your Boss" or "The case for git: delivering business value in IT" or "git vs TFS: how not to cripple your development team" or "git: because you don't just need to know how to program in language X, Y or Z".
历次讨论
同类还值得读
开源应用架构
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编辑精选