当两个或更多人将补丁集推到Gerrit中的相同变更集时，我正在努力寻找一个好的工作流程。多个开发人员推动相同的变化
我试图用命令行Git命令（无git-review，IDE等）完成此操作。
从Gerrit服务器上为特定更改拉下最新的修补程序集很容易，但从那里我不确定。
我认为这一进程将是：
但底垫中它将所有传入的更改标记为冲突，即使它们未在本地进行更改。
也许这与本地HEAD无法访问最新的下载补丁集有关。
任何人都可以建议多个开发人员可以在同一个更改上工作吗？
编辑： 回答这个问题，只显示在描述的技术：How to change a patchset and push it as a new one?
您的问题是gerrit本身。 gerrit中的变更集是一个单独的git提交，只要更改集作为审阅流程的一部分进行更改，就会被重写。因此，你会得到一个历史是这样的：现在
reviewed branch head --- changeset A, first revision
\-- changeset A, second revision
\- changeset A, third revision
，与你在你的问题拟定了工作流程，您尝试创建这段历史：
reviewed branch head --- changeset A, first revision --- changeset A, second revision
任何变化是出现在两个版本如果你这样做，会与自己冲突。
解决此的gerrit方式是获取变更的最新修订，修改变更，然后把它作为变更的一个新版本，取代了以前的变更，希望没有其他的开发人员已制作在此期间相同的变更集。最后一部分是基于gerrit的工作流无法实现纯粹使用纯git的做法：开发人员无法在同一个变更集上并行工作。这与纯粹的git形成鲜明对比，所有开发者可以自由地创建新的提交，分支和合并，然后git可以将所有的部分重新组合在一起。但为了这个工作，提交必须在git中保持不变，这是违反gerrit工作流程的原则。
如果你问我，最好的办法是避免使用gerrit。它的基本工作流程被破坏了，你可以更好地使用纯粹的git，这是由linux开发人员使用的。
请问为什么？通常情况下，变更由一个负责该变更的人员拥有。如果您需要多个开发人员来帮助您实现这一目标，那么听起来像这样的变化太大而复杂了，无法做出单一变更。 – poke
我知道不同的地方有不同的工作方式，但在我工作的一些地方，我们有一位软件开发人员和造型/主题设计师针对同一个问题开展工作，每个人都贡献自己特殊的专业知识。做出这些单独的变更集是不合适的，因为这些工作构成了单一的变更，而且这两个人的工作都不是孤立的。 –
@poke，开发人员一起修复一个bug的远程对编程是一个用例，其中一个定义明确的小改变可能会让多个开发人员将补丁集推向相同的变更集 –