我们目前使用 Gerrit，为一个大约十几个和一些开发人员的团队。
这是我们当前的工作流程:
1.开发者从master分支
2. 开发人员在他们本地的分支上工作
3. 开发人员推送到 gerrit，它通过在 refs/for/master 中包含推送的提交来保护 master 分支。 (如果您不知道，gerrit 也是存储库管理器。)
4. Gerrit 调用 Jenkins，在变更集上运行单元测试(和 Selenium 测试)。如果失败，提交将被踢回开发人员。否则，Jenkins +1s 提交。
5. 审阅者查看提交并为其 +1
6. 高级审阅者查看提交并+2s，变更集合并到 refs/head/master(即实际分支)
我们喜欢这个工作流程；这很棒。它为我们的开发带来了美妙且急需的流程和纪律，并从我们之前被忽视和忽略的代码审查瓶颈中列出了待办事项 list ，每个人都为此感到高兴。
x - 中场休息 - x
我们现在希望将我们的任务管理转移到 Jira。在我设置它的同时，我还设置了 Crucible，因为它似乎是让代码审查成为整个 shebang 的一部分的自然集成。我无法做的是重现我们喜欢的工作流程。使用 Jira/Crucible 集成，由于我们不再有我们的存储库把关一切(而且我们不想为 Atlassian 的 Stash 付费)，我们将把代码推送到 Bitbucket。我们不能再直接在 master 上工作，因为坏代码将不再是“守门员”，而是在通过任何测试或代码审查之前由开发人员合并到 master 中。让它远离主分支的唯一解决方案似乎是 fork 。好吧，这很烦人，但我可以接受。但是，如何在通过代码审查后从开发人员的分支中获取提交以合并到主分支中？这就是我想从那些做过任何类似事情的人那里听到的，或者在我的情况下知道如何完成它。
所有这些的替代方案是尝试使用 https://github.com/hobbs/jirret 强制在 Jira 和 Gerrit 之间进行集成。但这使用了 Jira 仍然支持但将不再进行任何开发的 XML RPC。
最佳答案
Vic，要从开发人员的分支中获取更改并将它们带入原始存储库的主代码行，您可以在 Bitbucket 中使用拉取请求。它们是对您正在进行的 Crucible 代码审查的补充。如果 fork 很麻烦，您可以尝试在您的存储库中创建一个“集成”分支，并让开发人员经常在那里推送代码(甚至在他们准备好进行同行评审之前)。该分支变成了一种汤，集成问题可以在其中浮出水面并得到解决，而不会污染 master。 Atlassian 的一些开发团队使用集成分支，并利用 Bamboo 的支持将 CI 方案自动应用到新分支，并在每次构建时自动合并分支。通常，每次将代码推送到 dev 分支时，您都会让 Bamboo 将您的 dev 分支合并到集成中。对于尽早发现冲突真的很有帮助。
链接到的博客 Matt 更详细地描述了这种工作流程。无论您使用什么 CI 工具，基本工作流都可以成功(尽管 Bamboo 确实对它有很好的支持和出色的 JIRA 集成)。
我希望这有帮助!
关于jira - 从 Gerrit 到 Crucible，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12015628/