Question

请考虑以下情形：2个用户A和B，其中包含同步的本地git存储库。两个用户HEAD都在开发分支上提交ID 1。用户a使用ID 2进行提交并将其推送到gerrit。用户B执行相同的操作并使用ID 3推送他的提交，ID 3经过审核和验证，因此会被推送到远程存储库。现在用户A做了一个拉动 - 基础。因此，他对ID 2的提交在用户B的提交ID 3之上进行了重新设置。由于重新设置，ID为1的提交将获得新的提交ID 4.

现在问题出现了：用户A对gerrit进行了另一次推送，因此再次推送ID为4（先前为1）的提交。更改ID保持不变，因为它只是一个rebase。虽然没有进行任何更改，但第二次提交将作为gerrit审核中的新补丁集进行威胁。考虑这种情况不止一次，然后你有几个补丁集，都有相同的变化！审阅者必须查看所有补丁集，通常都是相同的。

我的问题是：这真的应该是Gerrit的工作流程吗？或者我们做错了什么？

Answer 1

用户B可能不会一遍又一遍地改变他的工作。

有不同的Submit Actions可用和IIRC，除了仅限快进都可以在没有变基的情况下工作（如果分支发生变化）。

此外，UI中还有一个“Rebase”按钮，它会修改补丁并将评论传输到新的补丁集，以便人们不必再次投票。

长话短说：只要让用户B完成他的工作，而不是整天重新定位。

Answer 2

似乎与rebase有关，因为ID1不应该改变。最后，他应该具有ID1-> ID3-> ID4，其中ID4正式称为ID2。如果没有，那么你的基础是错误的。

建议的工作流程是始终在本地分支机构中工作。通过这种方式，您可以更好地控制合并，并且可以在准备集成和合并其他用户提交时进行集成。

# User A works in local branch A, user B works in local branch B
ID1->Branch A (ID2)-> Push to refs/for/master
   \-Branch B (ID3)-> Push to refs/for/master
# After ID2 is merged with the master, user B pulls and does a rebase locally
ID1->ID2
     \->Branch B (ID3) Rebase this branch to point to ID2
# After the rebase this is what it should look like
ID1->ID2->Branch B (ID4) Push to refs/for/master again

这是推荐的工作流程（我认为）

Gerrit在连续拉动后创建的多个补丁集

2 个答案: