从功能分支合并到母版之前进行代码审查的策略

我和我的团队使用功能分支（带有git）。我想知道哪种是合并到母版之前进行代码审查的最佳策略。

1. 我从master结帐了一个新分支，我们称它为fb_＃1
2. 我提交了几次，而不是想将其合并回母版
3. 在合并之前，应该有人进行代码审查

现在有两种可能性：

第一

1. 我将master合并到fb_＃1（不是将fb_＃1合并到master）以使其尽可能最新
2. 队友查看了主管和fb_＃1主管之间的变化
3. 如果fb_＃1可以，我们将fb_＃1合并到主服务器
4. 优点：审查中没有过时的代码
5. 缺点：如果其他人将“ 1”之间的内容合并。和“ 2”。他的更改将出现在评论中，尽管它们属于另一个评论。

第二名

1. 队友查看结帐点（git merge-base master fb_＃1）和fb_＃1 head之间的更改
2. 优点：我们可以清楚地看到在功能分支上所做的更改
3. 缺点：评论中可能会出现一些过时的代码。

您认为哪种方法更好？为什么？也许还有另一种更合适的方法？

您的第一个选项有所不同：

1. 将master合并到fb_＃1（不是将fb_＃1合并到master）以使其尽可能最新
2. 队友查看合并点上的主点和fb_＃1头之间的更改
3. 如果fb_＃1可以，我们将fb_＃1合并到主服务器
4. 快速检查合并是否正确

例如。

... ma -- ... -- mm -- ... -- mf  <- master
      \            \         /
       f1 ... fn -- fm -----      <-- fb_#1

哪里：

• ma是master和fb_＃1的祖先。
• fn是您分支机构的最后更改
• mm是合并到分支时的主/ HEAD提交（给fm）。

因此，您在初始审核中比较了mm和fm，然后在合并回mf之后迅速进行检查，以确保在步骤1-3中母版上没有任何重大变化。这似乎具有所有优点，而对于初审来说没有缺点。

这是假设与正常更改的频率相比，复审是快速的，因此fm-> mf通常是一个快速的过程。

如果不是这种情况，则无论出于何种原因，缺点都将从最初的审核转移到合并后的审核，而将其直接合并到母版并在其中进行单个审核可能会更简单。

第三名

• 你衍合分支上主既弥补最新和保留更改分开。

  这将创建分支的新历史记录。这将是具有相同ID的新修订版，具有相同的内容，但是将从最新的主修订版派生，并且不会链接到旧修订版。如果您需要引用旧修订，则仍然可以在“ reflog”中访问它们，例如，因为发现自己在解决冲突方面犯了错误。除此之外，他们一文不值。默认情况下，Git会在3个月后删除reflog并丢弃旧版本。

• 您可以使用交互式变基（git rebase -i和git commit --amend）对更改进行重新排序，编辑和清理，以便每个更改都进行逻辑上封闭的更改。

  这再次创建了新的历史记录，这一次具有附加的好处，即您可以重新组织更改以在审核期间最有意义。

• 优点：

  • 审查中没有过时的代码
  • 我们确切地看到了在功能分支上进行的更改
• 缺点：
  • 多做点事
  • 您必须注意不要为已经合并或共享的任何内容重新设置基址，并且收件人不希望它倒带。

通常，额外的工作意味着您首先要自己仔细检查代码，这也会遇到很多问题。

这就是Linux和Git所做的。在这些项目中看到一系列20到25个补丁程序进行审查并重写几次的情况并不少见。

实际上，Linux从项目的早期就开始这样做了，当时他们选择的版本控制是压缩包和补丁程序。多年以后，Linus着手创建git，这是实现rebase命令及其交互式变体的主要原因。也由于这个原因，git具有author和committer的独立概念。首先创建修订的是作者，最后接触修订的是提交者。由于在Linux和Git中，补丁仍然是通过电子邮件提交的，因此两者几乎永远不会是同一个人。

实际上，存在第三种可能性，并且可能还有很多其他可能性，因为GIT更是SCM框架的实现而不是SCM方法论的实现。第三种可能性基于rebase。

该rebaseGIT子命令将一系列提交（通常从分支点到你的主题分支的末端topic）和重放它们在其他地方（通常在您的集成分支的末端，如master）。该rebase子产生新的提交，其给出了一个形式，是比较容易审核清理提交的机会。这将产生一系列新的提交，类似于topic过去，但是植根于集成分支的顶部。topicGIT 仍会调用此新分支，因此旧引用将被丢弃。我非正式地标记topic-0了分支的原始状态，topic-1以此类推。

这是我对您的topic分支机构的建议：

1. （可选步骤）您可以交互式地将主题分支topic基于其分支点（请参阅和上的--fixup选项，commit以及-i和上的--autosquash选项rebase），这使您有机会以更易于查看的方式重写提交。这导致一个分支topic-1。

2. 您将主题分支重新设置到集成分支的顶部，类似于进行合并，但是通过“合并”（仅是软件工程工件）“不污染”历史记录。这导致一个分支topic-2。

3. 发送topic-2给队友，让其根据的提示进行审核master。

4. 如果topic-2可以，则将其合并到主服务器。

注意分支（分支指的是提交树）在GIT中将全部称为相同，因此，在过程结束时，只有分支topic-2在GIT中具有名称。

优点：

• 没有过时的代码正在审查中。
• 没有虚假的“外国合并”评论（您在第一篇中描述的现象）。
• 重写提交的机会很干净。

缺点：

• 在提交树中创建了topic-0三个分支工件topic-0， topic-1而不是一个分支topic-2。（尽管在任何时候，其中只有一个在GIT中具有名称。）

在您的第一种情况中，«如果有人在“ 1”之间合并了某些内容。和“ 2”»是指分支点的创建与您决定合并的时间之间的时间。在这种情况下，«如果有人在“ 1”之间合并了某些内容。和“ 2.”»指的是变基与合并之间的时间跨度，通常很短。因此，在我提供的方案中，您可以master在合并时“锁定” 分支，而不会显着干扰您的工作流程，而在第一种方案中则不可行。

如果您要进行系统的代码审查，则以适当的方式重新排列提交（可选步骤）可能是个好主意。

仅在您在存储库之间共享中间分支工件的情况下，管理它们才出现困难。