如果两个人的合作范围很窄，那么与Gerrit一起使用的工作流程是什么？

Question

我们的客户正在使用没有功能分支的Gerrit，到目前为止，他们通常对新故事有相当大的变更集。我们公司是代码库的新成员，因此我们成对地处理用户故事并分配工作。

Gerrit似乎只有很少的文档来解决1个提交者以外的场景：1个评论者。如果不是Gerrit及其坚持通过反复重写公共历史来分享变化，那么答案就是“共享一个功能分支，并在以后将其合并”＃34;例如，以下内容的工作流程是什么：

• Anne和Barney正在合作编写小部件列表的表单。
• 为了分解在大型预先存在的代码库上工作的认知负担，Anne将专注于＆＃34;后端＆＃34; - 在域模型中正确添加/删除/替换小部件;而Barney将在＆＃34;前端＆＃34; - 设计表单并编写UI代码。
• 设计是Anne将公开一个供Barney使用的IWidgetService。现在，这只是在UI和业务逻辑之间有一个很好的显式边界 - 这不是一个可以冻结的API，更不用说预先实现了。
• 这意味着Barney将需要稍微改变IWidgetService，但只需要对接口进行编码，然后将其留给Anne来实现更改，因为她知道那部分代码更好。

（改名以保护无辜者。）

在这种情况下，Anne和Barney究竟应该做些什么来同步他们的工作，同时也没有完全绕过基于评论的流程而只是为彼此的计算机设置一个遥控器？最好尽可能使用Git，因为Barney对Git来说是全新的，虽然Anne知道如何做一些Git手术，但她并不愿意。 （例如，坏=制作一个＆＃34;后端＆＃34;变更集和一个＆＃34;前端＆＃34;基于它的变更集，当任何一个变得更新时，做一些伏都教来正确地改变事物。）

Answer 1

当您尝试在旧系统上实施新时代的变更管理工作流程时，事情就会爆发。

• “相当大的变更集”很糟糕
• 将工作划分为“后端”和“前端”而不使用某种API是......不好
• 用户应该对git有一些了解

要解决 -

• 专心做小改动
• 确保更改不破坏系统
  （每次更改都应通过适当的自动验证）
• 尝试以减少开发人员之间的依赖关系的方式组织工作
• 尝试以减少组件之间依赖关系的方式组织产品
• 有一些工具可以帮助减轻开发人员的痛苦，例如 git-gerrit

修改

关于小变化，请考虑以下几组 non-breaking changes 作为示例：

1. 设计界面，即： 前端（“FE”）如何将请求发送到后端（“BE”）
   以及如何收到回复。
2. Gerrit-Change 1：实施界面
3. Gerrit-Change 2：实施BE 的存根，它将接收来自FE的请求
   并返回虚构（但有效）的回复
4. Gerrit-Changes 3,4：并行工作在BE和FE实施中 （将每个部分作为不同的更改提交）

将Change-1和Change-2推送到分支机构不应该破坏产品，
并允许在功能的实际实施上并行工作，
而不是强迫开发人员挑选彼此的工作 现在他们可以简单地git pull --rebase主要分支，就像普通人一样。

祝你好运！