Question

我的团队开始研究使用gerrit代码审查的项目。我们有自己的功能分支，工作需要一些时间，所以我们希望跟上开发分支的变化。

我们应该定期获取更改并将它们与我们自己的工作合并。每次合并之后，会有很多新的提交已经在开发分支上进行了审核。我们希望保留历史并避免压缩提交。我的问题是我们应该如何将所有更改推送到我们的分支机构。

推动审核没有多大意义，因为所有这些变化都已经过审核。在这种情况下直接推动好选择吗？什么是正确的工作流程？

Answer 1

对于gerrit，我可能会这样做：

使feature分支与上游分支master

保持同步

git checkout master
git pull
git checkout feature
git merge master

然后直接推到

，绕过审查

git push origin HEAD:refs/for/feature%submit

Answer 2

你绝对不应该压扁任何东西，除非你和你所有的开发者知道你在做什么，否则你也不应该改变任何东西。相反，从上游分支合并到您的功能分支，并上传生成的合并提交（refs / for / featurebranch）或直接将其推送到审核（refs / heads / featurebranch）。

合并提交的审查将不会非常有用，因为我认为它在Gerrit中显示为空提交，但作为流程的一部分进行代码审查可以让某人确认合并应该是制成。

非常频繁地执行此操作会创建一个有点混乱的历史记录，但您可以使用基本的Git命令列出分支之间的差异（git log --no-merges development..feature等）。