如果两个人进行狭隘协作，使用 Gerrit 的工作流程是什么？
What workflow to use with Gerrit if two people are collaborating narrowly?
我们的客户使用的是没有功能分支的 Gerrit，到目前为止，他们通常有相当大的新故事变更集。我们公司是代码库的新手，所以我们正在成对处理用户故事并分摊工作。
Gerrit 似乎很少有文档来解决 1 位提交者：1 位审阅者之外的场景。如果不是 Gerrit 及其坚持通过反复重写 public 历史来共享更改，答案将是 "share a feature branch and squash merge it later" 工作流将是什么，比如说，以下内容：
- Anne 和 Barney 正在共同开发一个用于编辑小部件列表的表单。
- 为了分担处理大型现有代码库的认知负担，Anne 将专注于 "backend" - 在域模型中正确添加/删除/替换小部件； Barney 将致力于 "frontend" - 设计表单并编写 UI 代码。
- 设计是Anne 将公开一个IWidgetService 供Barney 使用。现在，这只是为了在 UI 和业务逻辑之间有一个很好的明确边界——这不是一个可以冻结的 API，更不用说预先实施了。
- 这意味着 Barney 需要稍微更改 IWidgetService 将是经常发生的事情，但只是针对接口编写代码，然后让 Anne 实现更改，因为她知道那部分代码更好。
（为保护无辜者改名。）
在这种情况下，Anne 和 Barney 究竟应该做什么才能同步他们的工作，同时又不完全绕过基于审阅的流程而只是为彼此的计算机设置一个遥控器？最好尽可能地地道地使用 Git，因为 Barney 对 Git 是全新的，虽然 Anne 知道如何做一些 Git 手术，但她宁愿不知道。 （例如，坏 = 制作一个 "backend" 变更集和一个基于它的 "frontend" 变更集，当其中任何一个被更新时，做一些巫术来正确地重新设置基准。）
当您尝试在遗留系统上实施新时代的变更管理工作流程时，事情就崩溃了。
- "fairly large changesets" 不好
- 将工作分配给 "backend" 和 "frontend" 而没有某种 API 是......不好
- 用户应该对git
有一定了解
解决-
- 专心做小改变
- 确保更改不会破坏系统
（每个更改都应通过适当的自动验证）
- 尝试以减少开发人员之间依赖的方式组织工作
- 尝试以减少组件之间依赖性的方式组织产品
- 有一些工具可以帮助开发人员减轻痛苦，例如 git-gerrit
编辑：
关于小改动，请考虑以下一套
non-breaking changes举例：
- 设计界面，即：
前端（"FE"）如何将请求发送到后端（"BE"）
以及如何收到回复。
- Gerrit-Change 1：实现接口
- Gerrit-Change 2：为 BE 实现一个存根，它将接收来自 FE
的请求
和 return 一个虚构的（但有效的）回复
- Gerrit 更改 3,4：在 BE 和 FE 实现上并行工作
（将每个部分作为不同的更改提交）
将 Change-1 和 Change-2 推送到分支应该不会破坏产品，
并将允许并行处理该功能的实际实现，
无需强迫开发人员挑选彼此的作品。
现在他们可以像普通人一样简单地 git pull --rebase 主分支。
祝你好运！
我们的客户使用的是没有功能分支的 Gerrit，到目前为止，他们通常有相当大的新故事变更集。我们公司是代码库的新手，所以我们正在成对处理用户故事并分摊工作。
Gerrit 似乎很少有文档来解决 1 位提交者：1 位审阅者之外的场景。如果不是 Gerrit 及其坚持通过反复重写 public 历史来共享更改，答案将是 "share a feature branch and squash merge it later" 工作流将是什么，比如说，以下内容：
- Anne 和 Barney 正在共同开发一个用于编辑小部件列表的表单。
- 为了分担处理大型现有代码库的认知负担，Anne 将专注于 "backend" - 在域模型中正确添加/删除/替换小部件； Barney 将致力于 "frontend" - 设计表单并编写 UI 代码。
- 设计是Anne 将公开一个IWidgetService 供Barney 使用。现在，这只是为了在 UI 和业务逻辑之间有一个很好的明确边界——这不是一个可以冻结的 API，更不用说预先实施了。
- 这意味着 Barney 需要稍微更改 IWidgetService 将是经常发生的事情，但只是针对接口编写代码，然后让 Anne 实现更改，因为她知道那部分代码更好。
（为保护无辜者改名。）
在这种情况下，Anne 和 Barney 究竟应该做什么才能同步他们的工作，同时又不完全绕过基于审阅的流程而只是为彼此的计算机设置一个遥控器？最好尽可能地地道地使用 Git，因为 Barney 对 Git 是全新的，虽然 Anne 知道如何做一些 Git 手术，但她宁愿不知道。 （例如，坏 = 制作一个 "backend" 变更集和一个基于它的 "frontend" 变更集，当其中任何一个被更新时，做一些巫术来正确地重新设置基准。）
当您尝试在遗留系统上实施新时代的变更管理工作流程时，事情就崩溃了。
- "fairly large changesets" 不好
- 将工作分配给 "backend" 和 "frontend" 而没有某种 API 是......不好
- 用户应该对git 有一定了解
解决-
- 专心做小改变
- 确保更改不会破坏系统
（每个更改都应通过适当的自动验证） - 尝试以减少开发人员之间依赖的方式组织工作
- 尝试以减少组件之间依赖性的方式组织产品
- 有一些工具可以帮助开发人员减轻痛苦，例如 git-gerrit
编辑：
关于小改动，请考虑以下一套
non-breaking changes举例：
- 设计界面，即：
前端（"FE"）如何将请求发送到后端（"BE"）
以及如何收到回复。 - Gerrit-Change 1：实现接口
- Gerrit-Change 2：为 BE 实现一个存根，它将接收来自 FE
的请求 和 return 一个虚构的（但有效的）回复 - Gerrit 更改 3,4：在 BE 和 FE 实现上并行工作
（将每个部分作为不同的更改提交）
将 Change-1 和 Change-2 推送到分支应该不会破坏产品，
并将允许并行处理该功能的实际实现，
无需强迫开发人员挑选彼此的作品。
现在他们可以像普通人一样简单地 git pull --rebase 主分支。
祝你好运！