编程与软件工程mail-archive.com编辑精选
Linus 谈保持干净的 Git 历史（2009）
Linus on keeping a clean git history (2009)
2009 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这封 2009 年 DRI 开发者邮件列表中的邮件，是 Linus 关于如何保持 Git 历史干净的一次经典论述，被反复引用为 Git 工作流的参照。评论围绕提交粒度、合并与 rebase、以及能否改写公开历史展开，说明这些原则在实践中常被团队按自身情况调整。
为什么经久不衰：它来自 Git 作者本人，把版本控制从命令用法提升到历史叙事与协作规范，至今仍是团队设计 Git 工作流时的经典参照。
HN 评论精选
Git 强大但缺乏工作流指导，秩序只能靠社会约定，期待有产品在 Git 原语上提供更多约束。
这凸显了我唯一不喜欢 Git 的地方。它是一个能力极强的工具，但对“正确做法”不给任何指导。我们团队有一套与 Linus 这里所述相似但不同的实践，公司里不同项目又各自不同。最糟的是，除了约定俗成的社会规范，没有办法强制这些工作流或实践，所以小错误一直发生，我们的 Git 项目从没有本该那么漂亮。换句话说，Git 提供了一套极好的源码控制原语；我希望看到基于这些原语构建、能对项目施加更多秩序的产品。
lukev查看英文原文
This highlights the only thing I don't like about Git. It's an immensely capable tool, but it gives no guidance regarding the right way to do things. Our own teams have a set of practices which are similar but different from what Linus outlines here. And different projects on my company use different practices from those. The worst thing is that there's no way of enforcing these workflows or practices other than out-of-band social conventions. And so minor mistakes happen, all the time. Our Git projects are never as pretty as they should be. In other words, Git provides an awesome set of primitives for source control. I'm not sure what it'd look like, but I'd like to see a product that built on those primitives to enforce a little more order on projects.
合并可以保留分支历史、展示时只看合并点，因此质疑 rebase 的必要性。
我对 git 还比较新，不理解为什么 rebase 流行。如果我在分支 B 上工作，可以把它合并进 master M。合并点会有一条简洁消息“Bug Fix #1”。你可以只打印这些合并消息而不显示分支内杂乱历史。这不就和 rebase 一样吗？也就是说 rebase 去掉了杂乱的分支历史。但我更愿意保留那段历史，只是很少使用或展示它。bisect 也可以忽略那些分支而只用合并点。保留分支历史应该不是问题。我漏掉了什么？
silverlake查看英文原文
I'm still new-ish to git and don't get why rebase is popular. If I do my work on a branch B, I can merge this branch into the master M. The merge point will have a succinct message "Bug Fix #1". You can print the history so it only shows these merge messages and not the messy history in the branches. Isn't this the same as rebase? That is, rebase removes the messy branch history. But I'd prefer to keep that history, but rarely use or display it. bisect can also ignore those branches and only use the merge points. Saving the branch history shouldn't be problem. What am I missing?
清理历史存在粒度取舍，需要判断“干净”的标准，并担心丢失信息。
我对版本控制整体还比较新，但过去几年我们组一直在大力推行 Git。我最近一直在想：究竟期望/需要多少历史清理？开发时，我尽量把提交拆成许多小改动，使提交消息单一主题。我以为这基本上就是要点。偶尔我用 rebase 合并几个本应一起完成的提交，因为它们都解决同一问题。这在我看来都对。我得到的是我在非常细粒度时间尺度上所做一切的干净历史。但大量提交，每个对整体程序意义不大，掩盖了开发的大尺度结构。不过，我可以用 rebase 开始合并松散相关的提交，用时间分辨率换取提交历史的清晰度。这个尺度上似乎有一个连续谱。在这个连续谱上，哪里才算“足够干净”？另外，我不喜欢在失去完好信息的地方做改动。
smithzvk查看英文原文
So I'm relatively new to version control entirely, but in the last few years my group has been making a big push to institute Git. I have been wondering lately, however: how much history cleaning is expected/desirable? When I develop, I split my commits into as many small changes as I can so that the commit messages are single topic. I thought that was basically the idea. Every once in a while I use rebase to combine a few commits that should have been done together as they all addressed the same issue. This all seems right to me. I am left with a clean history of everything I have done on a very fine grained time scale. But the large number of commits, each with little significance to whole program hides the large scale structure of the development. However, I could use rebase to start combining loosely related commits, trading the time resolution for clarity in the commit history. There seems to be a continuum along this scale. Where is the proper place in that continuum to say this is clean enough? Also, I don't like making changes where I am losing perfectly good information. I know that I can group certain commits by defining a branch, developing on it, then merging (non-fast-forward) back to the original. The branch should keep the grouping in the commit history. I even suppose that this is can be done after the fact using rebase with the proper amount of git-fu. Is branching and non-fast-forward merges the preferred method of grouping related commits in the history? If so, this seems troubling as it means that partially fixing something is difficult to do with a clean history. Until the piece of the program you wish to fix is completely working, it shouldn't be merged into master because it would ruin the grouping of the related commits. This means that there can't be any partial thought's like fixing bugs as you find them, because presumably you might want to group all bug fixes of a function together, but have a distinct commit for each. Now I'm more confused than when I started. Seriously, any references or advice on this sort of topic are welcome.
“不改写公开历史”是经验法则而非铁律，小团队在约定下可安全改写。
我第一次读到“永远不要修改公开历史”之类常被重复的建议时，心想“是啊，废话”。不过我的看法有点改变，我认为这条建议符合一种常见模式：好的指导被错误地包装成绝不能打破的严格规则。实践中：我只在较小团队工作，我们用功能分支，评审后合入 master，净效果几乎没人直接在 master 上工作。所以如果某人推送提交，两天后发现拼写错误，或需要小代码改动，或任何可用微不足道的修改改进提交、不值得另建提交的情况，我们就直接 fixup/rebase/force push，也就是改写公开历史。因为团队其他人本来就对 master 做 pull --rebase 和/或 rebase 功能分支，这根本不是问题。
stinos查看英文原文
When I first read the often-repeated advice NEVER change public history or something along those lines I was like 'yeah, 'duh'. My opinion on that changed a bit though and I reckon this advice follows the standard pattern of good guidelines being falsely wrapped as strict rules which must never be broken. In practice: I only work in smaller teams and we use feature branches which get merged into master after review, having the netto effect pretty much no-one is ever working directly on master. So it if happens someone does something like pushing a commit only to figure out 2 days later it has a typo or even needs a small code change or anything which would improve the commit with trivial changes not really worth creating another commit, we just go ahead and fixup/rebase/force push i.e. rewrite public history. Since the rest of the team always does pull --rebase of master anyway and/or rebases feature branches this is not a problem at all.
历次讨论
同类还值得读
开源应用架构
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编辑精选