git-flow和github进行代码审查

使用常规的git和github，我可以通过简单地创建我正在处理的功能分支到master分支的拉取请求来进行代码审查。我将如何使用git-flow进行代码审查？使用“ git flow功能完成”之类的工作流程，我对代码审查实际上发生在何处以及git-flow或git如何促进该审查感到困惑。

我们最近偶然发现了这个确切的问题。我们非常喜欢git flow，因为它使用了很好的语义（使用与团队讨论相同的级别：“我将启动功能A”比“我将创建一个分支，将其检出”更多），而git是非常“实现”的级别（既好又有用，但有所不同）。

git feature finish我们遇到的问题是，它将分支合并到开发中，同时我们希望发送拉取请求，并且（这很重要）由审阅者（而不是提交者）合并，以强调团队所有权。

我们当前的解决方案：

1. 有人使用git flow创建功能分支
2. 完成后，他创建一个拉取请求（使用github）
3. 进行审核，并可能进行其他提交
4. 审阅者使用GitHub合并了pull请求。
5. 没有git flow功能完成（因为分支已经合并）

这与我们的做法是一致的，缺点是需要自己删除分支（因为我们没有进行git flow finish）。我们的下一步可能是重新实现git flow的某些部分（因为它主要是关于链接git命令）以考虑到这一点（具有完成的“清理”部分，没有合并）。

我与之合作的团队使用的流程如下：

1. 创建一个功能分支： git flow feature start module_1
2. 代码在功能分支上更新
3. 提交更改后，将它们推送到GitHub（如果愿意，则在末尾推送一次）
4. 功能完成后，将在GitHub中打开拉取请求，develop并与功能分支进行比较module_1
5. 团队审查拉动请求并发表评论
6. 对拉取请求所做的任何更改都会对功能分支进行
7. 将所有更改合并到功能分支后，功能分支即告完成： git flow feature finish module_1
8. 该develop分支被推向GitHub的（如封闭的/合并的GitHub将自动标记拉入请求时发生这种情况）

通常，所有这些过程都是由原始作者完成的，但这不是必需的。我们团队中的任何人都可以随时介入并进行此过程。他们要做的就是签出功能分支，然后继续进行此过程。谁曾运行过，git flow feature finish module_1都会删除其本地功能分支的奢侈功能，但其他签出该分支的人如果想使用，则必须手动执行此操作git branch -D feature/module_1。

对于修补程序，我们使用类似的方法并在完成修补程序之前在GitHub中创建拉取请求。

如果您要进行代码审查，那么我将假定您有一个包含“正式”代码的中央存储库。开发人员从该中央存储库中拉出并推送到该中央存储库。

当您使用Gerrit时，Gerrit本身便成为了中央存储库（它具有内置的SSH和HTTP服务器，使用户能够以与原来基本相同的方式与其进行交互）。使用Gerrit时，工作流程为：

1. 开发人员可以在任何分支上进行更改，并在本地提交。
2. 开发人员将这些更改推送给Gerrit。
3. Gerrit创建审阅项目，以供其他人审阅。
4. 同行审查代码，发表评论并接受或拒绝提交。
5. 当接受了提交，那么格里特使这些改变可为他人从分支拉。

使用中央存储库时，其他开发人员可以在步骤2之后看到提交的更改。Gerrit引入了代码检查工作流，因此其他开发人员仅在步骤5之后看到提交的更改。

这与git-flow（或任何其他分支方案）一起使用时效果很好，因为Gerrit支持查看在任何分支上所做的更改。

这是另一个建议。

1. 执行常规的git flow过程来创建功能，但不要完成或合并它。
2. 创建一个拉取请求，但不要合并它。等待批准者发表评论。评论是认可的标志。
3. 做git flow结束。（批准者或开发人员都可以执行此操作，具体取决于团队的共识。）pull请求将在github上标记为已合并。您仍然需要删除原点上的分支。