Accepting a messy git history

接受混乱的 Git 历史

As GitHub just released stacked pull requests, the discussion around it reveals two kinds of git users: Those who commit often and without much thought. Those who rebase carefully to craft a clean history. The commit-often people consider the rebase people as wasting time with pointless activities. A fine-grained history reflects how development actually happened. The rebase people consider the commit-often people as lazy and careless. Only with a clean history will it be possible to understand the intentions behind changes.

随着 GitHub 刚刚发布了“堆叠式拉取请求”（stacked pull requests），围绕这一功能的讨论揭示了两类 Git 用户：一类是频繁提交且不假思索的人；另一类是小心翼翼地进行变基（rebase）以构建整洁历史的人。频繁提交派认为变基派是在浪费时间做无意义的事，他们认为细粒度的历史记录反映了开发的真实过程。而变基派则认为频繁提交派懒惰且粗心，他们坚信只有整洁的历史才能让人理解代码变更背后的意图。

When stacking pull requests Looking at the HN discussion, you can see the commit-often people celebrating. Steve Klabnik: This is one of the biggest changes to hit GitHub in many years. I’m really glad to see something like this deployed to one of the largest forges in the world, hopefully it will expose a lot of developers to workflows that they didn’t even know about before. Meanwhile, the rebase people are puzzled, why anybody would want this. Insimwytim: I feel like many people (and industry in general) complicate things unnecessary.

在关于堆叠式拉取请求的 Hacker News 讨论中，你可以看到频繁提交派正在欢呼。Steve Klabnik 表示：“这是 GitHub 多年来最大的变革之一。我很高兴看到这样的功能部署在世界上最大的代码托管平台之一，希望它能让许多开发者接触到他们以前从未了解过的工作流。”与此同时，变基派感到困惑，不明白为什么会有人想要这个功能。用户 Insimwytim 评论道：“我觉得很多人（以及整个行业）都在不必要地把事情复杂化。”

When merging pull requests At work, we have a similar discussion about merging pull requests to main and if squashing is a good idea or not. The rebase people are angry if their carefully crafted history is destroyed by a squash merge. They prefer merge commits, such that every commit is preserved. The commit-often people love squash merges because it makes the history cleaner and easier to read. While it might be useful to have every step on a branch preserved as a separate commit, this messy history is not needed on the main branch.

在合并拉取请求时，我们在工作中也进行过类似的讨论：关于将拉取请求合并到主分支时，压缩提交（squash）是否是一个好主意。变基派会对他们精心构建的历史被压缩合并破坏而感到愤怒，他们更倾向于使用合并提交（merge commits），以便保留每一个提交记录。而频繁提交派则喜欢压缩合并，因为它使历史记录更整洁、更易于阅读。虽然在分支上保留每一步操作作为单独的提交可能很有用，但这种混乱的历史在主分支上确实是不必要的。

Who is right? Personally, I’m more of a rebase person. However, it requires discipline which is hard to maintain in larger organizations. If a clean history is not enforced very strictly, then the git history will become a mess. According to the broken window theory it tends to become worse and team rebase will eventually give up. Thus commit-often seems to be the more resilient approach and resistance is rather futile. So unless I have the authority over a git repository, I shall make peace with a messy history.

谁是对的？就我个人而言，我更倾向于变基派。然而，这需要极强的纪律性，而在大型组织中很难维持。如果不能严格执行整洁的历史记录规范，Git 历史最终会变得一团糟。根据“破窗理论”，情况往往会变得更糟，团队最终会放弃变基。因此，频繁提交似乎是一种更具韧性的方法，抵抗往往是徒劳的。所以，除非我对某个 Git 仓库拥有绝对的控制权，否则我还是选择与混乱的历史和解吧。