多个开发人员推动相同的变化 [英] Multiple devs pushing to same change

问题描述

我在努力寻找一个好的工作流程，当两个或更多的人把补丁集推到Gerrit的同一个变更集时。使用命令行Git命令（无git-review，IDE等）完成此操作。

从Gerrit服务器中取出最新的修补程序集以进行特定更改很容易，但从那里我不知道。

我认为这个过程将是：

• 从服务器获取最新补丁集


• 兑换最新补丁集


• push



$ b

但是在重新绑定期间，即使它们没有在本地进行更改，它也会将所有传入的更改标记为冲突。





也许这与下面这一事实有关：HEAD本地无法访问最新的补丁集。





任何人都可以提出多个开发人员可以如何工作同样的变化？





编辑：
这个问题的答案与以下所述的技术一起显示：如何更改补丁集并将其作为新补丁集？

解决方案

您的问题是 gerrit 本身。 gerrit 中的变更集是一个单独的 git 提交，只要更改集作为审阅流程的一部分进行更改，就会被重写。因此，您将获得如下历史记录：



 已审核分支头---变更集A，第一次修订
 \\ \\  -  changeset A，second revision 
 \ -changeset A，third revision 
  

现在，你在你的问题中勾画的工作流程，你试图创建这个历史：第一次修订---变更集A，第二次修订


如果你这样做会与自己发生冲突。





解决这个问题的方法是 gerrit 获取变更集的最新版本，修改变更集，然后将其作为变更集的新修订版，替换以前的变更集，希望其他开发人员在此期间没有对同一变更集进行工作。最后一部分是基于 gerrit 的工作流程无法实现纯粹 git 的微不足道的事情：开发人员可以' t在同一变更集上并行工作。这与纯粹的 git 形成了鲜明的对比，所有开发者都可以自由地创建新的提交，分支和合并，而能够将所有作品重新放在一起。但为了达到这个目的，提交必须在 git 中保持不变，这是违反 gerrit 工作流程的原则。 / p>



如果你问我，最好的办法是避免使用 gerrit 。它的基本工作流程已经被破坏，并且你更好地使用纯粹的 git ，这是由linux开发者使用的方式。




I'm struggling to find a good workflow when two or more people are pushing patch-set's to the same change-set in Gerrit.

I am trying to accomplish this with command-line Git commands (no git-review, IDE, etc).

Pulling down the latest patch-set from the Gerrit server for a particular change is easy enough, but from there I'm not sure.

I would think the process would be:

• fetch latest patch-set for change from server
• rebase against latest patch-set
• push

But during the rebase it marks all incoming changes as conflict, even if they weren't altered locally.

Perhaps this is related to the fact that the latest patch-set downloaded is not reachable by HEAD locally.

Can anyone suggest how multiple developers can work on the same change?

EDIT: The answer to this question are shown with the techniques described in: How to change a patchset and push it as a new one?

解决方案

Your problem is gerrit itself. A changeset in gerrit is a single git commit that's rewritten whenever the changeset is changed as a part of the review process. As such, you get a history like this:

reviewed branch head --- changeset A, first revision
                     \-- changeset A, second revision
                      \- changeset A, third revision

Now, with the workflow you sketched in your question, you attempt to create this history:

reviewed branch head --- changeset A, first revision --- changeset A, second revision

Any change that is present in both revisions will conflict with itself if you do this.

The gerrit way to work around this is to fetch the latest revision of the changeset, amend the changeset, then push it as a new revision of the changeset, replacing the previous changeset, hoping that no other developer has worked on the same changeset in the meantime. The last part is where a gerrit based workflow fails to achieve what is trivial to do with pure git: Developers can't work in parallel on the same changeset. This is in stark contrast to pure git, where all developers can freely create new commits, branch, and merge however they please, and git is able to put all the pieces back together. But for this to work, commits must be constant in git, a principle that is violated by the gerrit workflow.

If you ask me, the best thing to do is to avoid using gerrit. It's basic workflow is broken, and you are much better of using pure git in the way that it is used by the linux developers.

这篇关于多个开发人员推动相同的变化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！