gerrit(2) | 为什么使用 gerrit

gerrit(2) | 为什么使用 gerrit

本文以 Use Gerrit to Be a Rockstar Programmer 的翻译为基础， 增加一点个人笔记。

依照惯例， 中文的括号里是个人的粗浅看法。

概要 (Overview)

The term rockstar is often used to describe those talented programmers who seem to work faster and better than everyone else, much like a composer who seems to effortlessly churn out fantastic music. However, just as the spontaneity of masterful music is a fantasy, so is the development of exceptional code.

“摇滚明星”这个词经常用来形容那些比其他人工作更快更好的有才华的程序员，就像作曲家似的毫不费力地创作出了惊人的音乐一样。然而，就像精湛音乐的自发性一样，卓越代码的开发也是一个幻想。
（10倍程序员、全站程序员的说法，早就听说过了， 这些人产出高是事实； 作者似乎认为， 这些高质量的产出是需要练习而得到的？）

The process of composing and then recording music is painstaking — the artist records portions of a composition over and over, changing each take until one song is completed by combining those many takes into a cohesive whole. The end result is the recording of the best performance of the best version of the song.

创作然后录制音乐的过程是很费力的——艺术家一遍又一遍地录制作品的部分，改变每次的录音，直到通过将这些多次录音合并成一个连贯的整体来完成一首歌曲。最终结果是录制下了这首歌最佳版本的最佳表演。
(台上一分钟， 台下十年功 – 貌似说的有点夸张， 但是对于作曲家来说， 是经过练习而不是一下子演奏出高质量的曲子)

Consider Queen’s six-minute long Bohemian Rhapsody, which took three weeks to record. Some segments were overdubbed 180 times!

考虑一下女王乐队演唱的长达六分钟的《波西米亚狂想曲》，录制这首歌花了三个星期的时间。有些部分甚至进行了180次的重叠录音！

Software engineering is much the same. Changes that seem logical and straightforward in retrospect actually required many revisions and many hours of work before they were ready to be merged into a code base. A single conceptual code change (fix bug 123) often requires numerous iterations before it can be finalized. Programmers typically:

软件工程也是如此。事后看来似乎合乎逻辑且直截了当的改变实际上需要许多修订和许多工作小时，然后才能准备好合并到代码库中。一个概念上的代码变更（修复错误123）通常需要多次迭代才能最终确定下来。程序员通常：
（简洁的代码， 你看着挺自然， 但是可能是经过反复推敲修改的）。

• 修复编译错误 (Fix compilation errors)
• 提取一个方法，避免重复代码 (Factor out a method, to avoid duplicate code)
• 使用更好的算法，使其更快 (Use a better algorithm, to make it faster)
• 处理错误条件，使其更加健壮 (Handle error conditions, to make it more robust)
• 添加测试，防止错误再次出现 (Add tests, to prevent a bug from regressing)
• 调整测试，以反映更改的行为 (Adapt tests, to reflect changed behavior)
• 优化代码，使其更易阅读 (Polish code, to make it easier to read)
• 改进提交信息，解释为什么进行了更改 (Improve the commit message, to explain why a change was made)
  （这一段是说， clean code， 单元测试， 甚至 commit message 的编写也要符合规范）

In fact, first drafts of code changes are best kept out of project history. Not just because rockstar programmers want to hide sloppy first attempts at making something work. It’s more that keeping intermediate states hampers effective use of version control. Git works best when one commit corresponds to one functional change, as is required for:

实际上，最好将代码更改的初稿保留在项目历史记录之外。这不仅仅是因为rockstar程序员想要隐藏制作东西的杂乱初次尝试。更重要的是，保留中间状态会妨碍有效使用版本控制。Git 在一个提交对应一个功能性更改时效果最佳，这也是必需的。

（好的代码仓库， 连代码提交历史也是清爽的。 Every git commit counts. 每个 commit 都要有意义, 功能达到最佳。 感觉这挺难的）

Git 在进行版本控制时，最好是一个提交对应一个功能性的改变，这对以下操作是必须的：

• git revert
• git cherry-pick
• git bisect

修订提交 (Amending commits)

Git provides a mechanism to continually update a commit until it’s perfect: use git commit --amend to remake (re-record) a code change. After you update a commit in this way, your branch then points to the new commit. However, the older (imperfect) revision is not lost. It can be found via the git reflog.

Git提供了一种机制，可以不断更新提交，直到完美为止：使用git commit --amend重新制作（重新记录）代码更改。以这种方式更新提交后，您的分支将指向新的提交。但是，旧的（不完美的）修订版本并没有丢失。可以通过git reflog找到它。
（问题在于： git reflog 里记录的东西， 在 git remote 上不会永远存在。。）

代码审查 (Code review)

At least two well-known open source projects insist on these practices:

至少有两个知名的开源项目坚持这些做法：

• Git
• Linux Kernel

However, contributors to these projects don’t refine and polish their changes in private until they’re perfect. Instead, polishing code is part of a review process — the contributor offers their change to the project for other developers to evaluate and critique. This process is called code review and results in numerous benefits:

然而，这些项目的贡献者并不会在私下里完善和润色他们的改动直到完美为止。相反，润色代码是审查过程的一部分 - 贡献者将他们的改动提交给项目，供其他开发人员评估和批评。这个过程被称为代码审查，带来了许多好处：

Code reviews mean that every change effectively has shared authorship

代码审查意味着每一次变更都有共同的作者。 （code review 意味着多个人共同完成了最终的代码）

Developers share knowledge in two directions: Reviewers learn from the patch author how the new code they will have to maintain works, and the patch author learns from reviewers about best practices used in the project.

开发人员在两个方向上分享知识：审阅者从补丁作者那里学习新代码的工作原理，而补丁作者则从审阅者那里了解项目中使用的最佳实践。
(有两个角色： 提交补丁的人， 以及审核代码的人。 相互学习。)

Code review encourages more people to read the code contained in a given change. As a result, there are more opportunities to find bugs and suggest improvements.

代码审查鼓励更多的人阅读特定更改中包含的代码。因此，有更多的机会发现错误并提出改进建议。
（code review 鼓励的是： 在一次代码修改中， 让更多人的阅读修改的代码， 是的更容易发现 bug 和改进的地方。 然而， 对方万一发现了也不肯说呢？ 万一 Team Leader 不肯开放代码权限， 只让单个人和 Team Leader 本人有权看代码， 其他人就算水平很高也不能参与进来呢？）

The more people who read the code, the more bugs can be identified. Since code review occurs before code is submitted, bugs are squashed during the earliest stage of the software development lifecycle.

阅读代码的人越多，就能发现更多的bug。由于代码审查发生在代码提交之前，因此在软件开发生命周期的最早阶段就能消除bug。
（好嘛， 越多的人读代码就约可能发现问题， 那么干脆开源算了， 完全开源是最好的。 真的么？)

The review process provides a mechanism to enforce team and company policies. For example, all tests shall pass on all platforms or at least two people shall sign off on code in production.

审查流程提供了执行团队和公司政策的机制。例如，所有测试都必须在所有平台上通过，或者至少有两个人必须签署生产代码。
（搞得很严格： code review 是说， 代码要在所有平台上通过所有单元测试， 至少有两个人必须同意才能合并代码）

Many successful software companies, including Google, use code review as a standard, integral stage in the software development process.

许多成功的软件公司，包括谷歌在内，都将代码审查作为软件开发过程中的标准和重要阶段。
（成功的软件公司， 确实是看重 Code Review 的）

基于 Web 的代码审查 (Web-based code review)

To review work, the Git and Linux Kernel projects send patches via email.

Git 和 Linux 的代码， 通过邮件发送

Code Review (Gerrit) adds a modern web interface to this workflow. Rather than send patches and comments via email, Gerrit users push commits to Gerrit where diffs are displayed on a web page. Reviewers can post comments directly on the diff. If a change must be reworked, users can push a new, amended revision of the same change. Reviewers can then check if the new revision addresses the original concerns. If not, the process is repeated.

代码审查（Gerrit）为这个工作流程添加了现代的网页界面。与通过电子邮件发送补丁和评论不同，Gerrit 用户将提交推送到 Gerrit，在那里差异显示在一个网页上。审阅者可以直接在差异上发表评论。如果需要重新修改，用户可以推送同一更改的新修订版本。审阅者随后可以检查新版本是否解决了最初的问题。如果没有，就重复这个过程。
（Git 和 Linux kernel 真的太老派了； 咱 Gerrit 很先进的 – 在网页上显示代码差异， 你在差异的代码上可以评论。 提交后的修改， 被review后，或者自己发现了bug，可以继续增量式的提交修改）

格里特的魔法 (Gerrit’s magic)

When you push a change to Gerrit, how does Gerrit detect that the commit amends a previous change? Gerrit can’t use the SHA-1, since that value changes when git commit --amend is called. Fortunately, upon amending a commit, the commit message is retained by default.

当您向Gerrit推送更改时，Gerrit如何检测提交是否修改了先前的更改？Gerrit无法使用SHA-1，因为当调用git commit --amend时，该值会发生变化。幸运的是，在修改提交时，默认情况下会保留提交消息。

This is where Gerrit’s solution lies: Gerrit identifies a conceptual change with a footer in the commit message. Each commit message footer contains a Change-Id message hook, which uniquely identifies a change across all its drafts. For example:

这就是Gerrit的解决方案所在：Gerrit在提交消息的页脚中标识了一个概念性的变化。每个提交消息的页脚都包含一个Change-Id消息挂钩，它可以唯一地标识所有草稿中的变化。例如：

Change-Id: I9e29f5469142cc7fce9e90b0b09f5d2186ff0990

Thus, if the Change-Id remains the same as commits are amended, Gerrit detects that each new version refers to the same conceptual change. The Gerrit web interface groups versions so that reviewers can see how your change evolves during the code review.

因此，如果 Change-Id 在提交修订时保持不变，Gerrit 会检测到每个新版本指的是同一个概念性变更。Gerrit 网页界面会将各个版本分组，以便审阅者可以看到您的变更在代码审查过程中是如何演变的。

To Gerrit, the identifier can be random.

对于Gerrit来说，标识符可以是随机的。

Gerrit provides a client-side message hook to automatically add to commit messages when necessary.

Gerrit提供了一个客户端消息挂钩，可以在必要时自动添加到提交消息中。

个人总结

• Gerrit 是一个 code review 的系统
• gerrit 和 git 无缝连接
• gerrit 在网页上显示提交的代码修改，并且可以在修改的地方添加评论
• 对于多次代码修改， git 本身是支持 git commit --ammend 的， 不过这会导致 SHA-1 的变更
• gerrit 的解决方案是， 绑定一个 Change-Id 到 commit message, 虽然 SHA-1 变了， 但是 Change-Id 不变， 就能维持