Gerrit跟踪功能分支？ [英] Gerrit with tracked feature branches?

问题描述

我们（git / gerrit newbs）正在尝试将gerrit与特性分支结合使用。我们试图实现的工作流程如下：

1. 用户创建一个功能分支，直接将其推送到远程仓库（无需评论） git push -u原始用户分支。


2. 当更改堆积在主分支中时，用户将执行 git pull --rebase origin master - rebase 是必须的，否则git会创建合并提交，并且合并提交不能通过gerrit ）。


3. 用户继续使用 git push --force origin users-branch （<$ c因为 - rebase 在前一阶段需要$ c> --force ;我正在寻找更好的方法来完成此操作） 。
   
4. 其他用户可以通过推送自己的更改来为功能分支做出贡献。


5. 功能准备就绪时，用户将其按 git push origin HEAD：refs / for / master 。

最后一步不起作用，因为c在任何阶段推送到gerrit的ommits不能再次推送。

gerrit手册建议修改您想要再次推送的提交。这看起来很复杂且容易出错。

如果用户从不将他的更改推送到远程repo，那么这一切都可以正常工作，因为gerrit在推送审阅之前不会看到更改。但这正是我们不喜欢的。

似乎可以使用不同的回购功能分支，例如gerrit从不会看到重复的变更ID，但这又似乎是一个不必要的复杂因素。 b
$ b

有没有办法做到我们想要的安全和优雅？

解决方案

至少运行 Gerrit 2.11 ，您可以从中受益修复 issue 1195 ，并启用创建新的更改为所有目标选项可以考虑目标当确定新的分支时更改为打开。

We (git/gerrit newbs) are trying to use gerrit with feature branches. The workflow we are trying to implement is as follows:

1. User creates a feature branch, pushes it to the remote repo directly (no review) with git push -u origin users-branch.
2. As changes pile up in the master branch, user does git pull --rebase origin master (--rebase is needed because otherwise git creates a merge commit, and merge commits cannot be pushed through gerrit).
3. User continues to push his changes to the remote repo with git push --force origin users-branch (--force is needed because of --rebase at the previous stage; I'm looking for a better way to do this).
4. Other users can contribute to the feature branch by pushing their own changes.
5. When the feature is ready, the user pushes it for review with git push origin HEAD:refs/for/master.

The last step doesn't work because commits that were pushed to gerrit at any stage cannot be pushed again.

The gerrit manual suggests to amend the commits you want to push again. This seems complicated and error prone.

It all works if user never pushes his changes to remote repo, because gerrit doesn't see the changes until they are pushed for review. But this is exactly what we don't like.

It seems possible to use a different repo for feature branches, such that gerrit never sees duplicate change IDs, but this again seems like a needless complication.

Is there a way to do what we want safely and elegantly?

解决方案

If you're running at least Gerrit 2.11 you can benefit from the fix for issue 1195 and enable the create-new-change-for-all-not-in-target option to take into account target branch when determining new changes to open.

这篇关于Gerrit跟踪功能分支？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！