我们有两个不同的团队，每个团队都在自己的位置，使用 git，每个位置都有一个参考存储库。每个位置都可以访问企业网络，但两个网络不能直接连接（相信我，我们问过）：我们只能交换文件。我们希望能够定期同步这两个位置，以便可以通过各自的参考存储库共享工作。
要求：
- 必须允许双向交换。
- 我们需要能够同时在双方的某些分支上工作，或者至少从发生这种情况的情况中恢复，即使我们希望大部分时间都在单独的分支上工作。这意味着可能需要一个集成步骤来处理不同的工作。
- 大多数跟踪必须自动发生，以便最大限度地减少人工干预和操作错误的风险（并不是说它们会致命，但最好避免相互指责：信任是有限的）。特别是，在 git-bundle 手册页中使用的单个移动标签示例是可笑的，因为它甚至无法扩展到有限数量的分支（我们有几十个）。
- 参考存储库只能通过远程推/拉和必要的轻管理操作进行操作，这既是因为它们在 IT 控制之下，也是因为我们希望它们始终保持一致，即首先完成集成，然后才进行更改另一方与集成一起在本地参考存储库上发布。
- 我们不能每次都发送整个存储库（甚至是 tar-gzip）：它不仅本身有点大，而且所有连续发送的包都保存在记录中，因为这是合同承诺的一部分，并且在其中有 N 个存储库副本很快就会变得不可持续。
- 所有必要的信息都必须存储在本地参考存储库中，以便任何开发人员都可以执行同步步骤，而无需依赖存储在特定开发人员的本地存储库中的信息。
- 使用 git，而不是反对它，至少尽可能多地这样做。工作流程越怪异，就越有可能因为 git 的变化或其他意外情况而中断。
非要求：
- 处理两个以上断开连接的站点。两个已经足够具有挑战性了。
- 每晚处理。交换将被手动触发和处理。
- 命令的数量或复杂性有限。如果需要许多复杂的命令，就这样吧，我们总是可以在脚本中隐藏这种复杂性。
- 跨越离线同步。这总是意味着麻烦，就像流一样。因此，我们可以假设离线同步操作是完全有序的，无论它们的方向如何，必要时轮流进行。
- 分公司管理细节等。那是我们内部的业务。