本地中央git存储库的离线同步

Question

我们有两个不同的团队，每个团队都在自己的位置使用git，每个位置都有一个引用存储库。每个位置都可以访问一个企业网络，但这两个网络不能直接连接(相信我，我们问过了)：我们只能交换文件。我们希望能够定期同步这两个位置，以便通过各自的参考存储库共享工作。

所需经费：

• 必须允许在任何一个方向进行交流。
• 我们需要能够同时处理来自双方的一些分支，或者至少能够从发生这种情况的情况中恢复过来，即使我们大部分时间都希望在不同的分支上工作。这意味着可能需要一个集成步骤来处理发散的工作。
• 大多数跟踪必须是自动发生的，因此手动干预和操作错误的风险被最小化了(不是说它们会致命，而是最好避免指责:信任是有限的)。特别是，git-bundle手册页中使用的单个移动标记示例是可笑的，因为这甚至不会扩展到有限的分支(我们有几十个分支)。
• 引用存储库只能通过远程推送/拉操作来操作，如果必要的话，还可以通过轻松的管理操作来操作，这既是因为它们处于IT控制之下，也是因为我们希望它们始终保持一致，即集成是首先完成的，只有到那时，来自另一方的更改才会与集成一起发布在本地引用存储库上。
• 我们不能每次发送整个存储库(甚至tar-gzipped)：它本身不仅有点大，而且连续发送的所有包都被保存在记录中，因为这是合同约定的一部分，在其中拥有N个存储库副本将很快变得不可持续。
• 所有必要的信息必须存储在本地参考存储库中，以便任何开发人员都可以执行同步步骤，而不依赖于存储在特定开发人员的本地存储库( in )中的信息。
• 与git一起工作，而不是反对它，至少在可能的范围内这样做。工作流越奇怪，它就越有可能因为git或其他意外情况的改变而崩溃。

非所需：

• 处理两个以上断开的站点。两个已经够有挑战性的了。
• 夜间处理。交换将被手动触发和处理。
• 有限的命令的数量或复杂性。如果有许多复杂的命令是必要的，那么，我们总是可以在脚本中隐藏这种复杂性。
• 穿越离线同步。这总是意味着麻烦，就像溪流一样。因此，我们可以假设离线同步操作是完全有序的，不管它们的方向如何，必要时轮流操作。
• 分公司管理细节等，那是我们的内部业务。

Answer 1

到目前为止，我的解决方案是使用git bundle命令，依靠远程引用来跟踪另一个位置已经有了什么，其中包括我想出的一些步骤，以便通过push/pull进行这些远程引用。让我们的位置被称为站点-a和远程位置被称为站点-b。

• 生成要发送到远程位置的包：

1. `~/work$> git clone $LOCAL_REF_URL --mirror bundler`
2. `~/work$> cd bundler`
3. `~/work/bundler$> git bundle create ../bundle-site-a-$(date +%Y-%m-%d) --branches --tags --not --remotes=site-b`

bundler工作库现在可能被丢弃。

• 集成来自远程位置的包：

1. `~/work$> git clone -n $LOCAL_REF_URL bundle-integration`
2. `~/work$> cd bundle-integration`
3. `~/work/bundle-integration$> git checkout --detach`
4. `~/work/bundle-integration$> git fetch origin 'refs/heads/*:refs/heads/*' 'refs/remotes/site-b/*:refs/remotes/site-b/*'`
5. `~/work/bundle-integration$> git remote add site-b ../bundle-site-b`
6. `~/work/bundle-integration$> git fetch --tags site-b 'refs/heads/*'`
7. At this point the fetch told which remote site-b branches were updated with info from the bundle, so insert here the work necessary to integrate the ones that have corresponding branches in our location; first a `git fetch . 'refs/remotes/site-b/*:refs/heads/*'` to fast-forward the ones that can be in one fell swoop, then `git checkout $BRANCH && git merge site-b/$BRANCH` for the others: neither side of history can be rewritten. Also delete branches that the bundle took into account but no longer contains.
8. If `git push --tags origin 'refs/heads/*:refs/heads/*' 'refs/remotes/site-b/*:refs/remotes/site-b/*' --prune` fully succeeds, return; we are done
9. `~/work/bundle-integration$> git fetch origin` (a regular one)
10. Take into account work done on your location that happened while you were busy performing the previous steps; that still has to be done with merge (though in the more usual `git checkout $BRANCH && git merge origin/$BRANCH` idiom), except for your own merging work, which can be rebased if you prefer
11. goto 8

现在，包集成工作存储库可能被丢弃。

注意:第1步不能仅仅是一个镜像克隆，因为--镜像不仅仅是假设-裸露的，它是强制的，这与以后执行集成的需要是不相容的:即使是琐碎的(快速转发) git合并操作也需要一个非空的存储库。为了将HEAD“停放”于任何分支之外，步骤3是必要的，否则，如果步骤4试图直接更新HEAD所指向的分支，则步骤4将失败。步骤4是必要的(它不获取任何提交)，因为它将设置所有必要的引用，因为远程包可能不一定包含所有分支(它忽略了不提供更新的分支)，而最终我们将根据自己的分支从原始分支中删除分支，因此我们希望从所有原来的分支开始；将此步骤中的规范指定为初始克隆的-c选项，而不是看起来有效。步骤5是必要的，因此git知道在步骤6中更新refs/remotes/site-b/*中的引用。

• 当远程位置确认能够获取发送给它们的包的内容时，更新远程跟踪引用： 这是通过遵循从“从远程位置集成一个包”的步骤来完成的，除非将发送的包看作是来自远程位置的；显然，在这种情况下不需要进行集成工作，因为来自我们位置的分支必须与来自该包的信息更新。