版本控制不是软件开发中最有趣的问题，并且由于Github的无处不在，许多组织只是觉得这已经被解决了。 但是，使用Git对软件进行版本控制的方法有另一种，当人们不知道它时，我总是感到惊讶。 这是一个鲜为人知的代码审查工具，最初由Google为开发Android而开发。 如今，有很多方法可以帮助您了解Gerrit，但在进行此操作之前，请先备份一下。
Gerrit的核心是代码审查工具，但其工作方式可能会对团队的工作流程产生更大的影响。 Gerrit充当开发人员和实际git存储库之间的中间人。 您无需将提交直接推送和合并到您的存储库中，而是将它们推送到Gerrit，在那里可以对它们进行代码审查和验证之类的工作（稍后再介绍）。 在Gerrit中暂存后，原始开发人员可以在其计算机上编辑或更改提交，然后可以将其再次推送到Gerrit。 通过一个神奇的“ Change-Ids”系统，Gerrit可以跟踪所有提交的所有版本，并创建“补丁集”-单个提交的堆栈，这些堆栈可以跟踪您的所有编辑和迭代。 它还将那些补丁集与其他相关的提交相关联，从而创建了一个可单独查看，编辑和合并的提交堆栈。 运作方式如下：
每次开发人员将提交的新版本推送到Gerrit时，系统都会为该提交创建补丁集列表。 使用此系统，代码审阅者可以使用Gerrit Web门户查看每个补丁集相对于其任何前任产品的逐行差异，以确切查看更改内容。
注意右上角显示“补丁集（2/2）”的地方吗？ 这意味着我推送了此提交的2个不同版本。 我推了一个，有人对此发表了评论，然后我推了另一个，以解决这些评论。 现在，审阅者不仅可以查看提交中的更改，还可以查看此版本的提交与最后一个版本之间的更改。 这对于检查是否满足所有代码审查要求非常有用。
还要注意，屏幕快照中的提交是堆栈中全部11个提交之一。 这意味着审阅者可以分别查看每个提交，对每个提交进行评论，然后开发人员可以编辑每个提交并推送整个新堆栈。 当这被合并到仓库中时，提交日志将是一个清晰，详细的详细提交列表，并且每个提交都将经过编辑以符合团队的标准。
您如何编辑提交？ 很高兴你问
变魔术
当按设计使用Gerrit系统时，会将所有旧的Github样式的合并提交替换为基础。 对于不熟悉rebase的任何人，它们就像魔术般的合并。 在合并中，您的更改将“重放”在另一个分支的顶部，并且所产生的更改将捕获到新的提交中。 这是一个合并提交 …您未编写的提交，但是Git会为您生成并包括您要合并到的分支的更改解析。 一旦合并提交进入您的历史记录，还原合并中涉及的单个提交将变得更加困难。 使用重定基，会发生非常类似的过程-您的提交被重播到另一个分支上-但是区别在于重定基重播了您的提交，就好像它们最初是在新分支的技巧上被提交的一样。 这意味着完成后，您的提交堆栈就整齐地位于新分支的顶部，就好像您是从头开始的。 从读取提交日志到还原单个提交，这使一切变得更加简单。 它非常干净，您实际上可以将未经编辑的提交日志用作完整的构建说明集，而无需进行特殊处理。 Rebases还使您可以将整个已编辑的提交堆栈推入并重新推送到Gerrit，并为每个提交创建补丁集，同时仍将这些提交关联到一个逻辑依赖性列表中。
现在，让我们考虑使用典型的Github工作流程的相同情况。 首先，所有11个相关的提交通常都将成为单个Pull-Request的一部分。 通常，审阅者甚至不会费心地审阅每个提交，而是一次审阅整个请求中的所有更改，并可能同时评论多个提交。 发生这种情况的原因是提交的作者无法返回并编辑堆栈中的单个提交，因此没有必要检查每个提交。 如果审阅者要对每个提交发表评论，则作者可以单独编辑它们的唯一方法是创建一个全新的PR，在这种情况下，原始评论将丢失，或者强制将新的提交堆栈推到顶部现有的，完全放弃了原来的变化。 因此， 开发人员通常 会在处理评论评论的所有其他事物之上 推动 新的提交。
这个系统很快变得一团糟。 不仅您的存储库中充斥着PR中的合并提交，而且很难从这些合并中的一个还原单个提交。 除了这些问题之外，您还可以在历史记录中找到一份完整的提交清单，这些清单可以简单地解决一堆先前提交的不同，有时不相关的代码审查注释。 随着时间的流逝，那些“地址审查评论”提交变得越来越难以理解。 而且，如果您想知道为什么要进行这些更改，那么祝您好运。
除了保持您的存储库整洁和提交日志可读之外，Gerrit还保留每个提交的历史记录以及每个审阅者对这些提交的评论。 如果您想知道为什么要在代码中进行一些随机更改，则可以在Gerrit中找到提交，并查看其整个历史记录以查看提示每次编辑的内容。
因此，Gerrit使您的版本历史记录更加整洁，但也可以帮助您通过健全性检查来验证提交，并保护您的存储库免受意外编译错误的影响。 这一切如何运作？ 敬请关注。
下次： 使用Gerrit和持续集成来验证代码
