我有两个房间，使用git维护一些源代码，“dev”房间是大部分开发的地方，“deploy”房间是我们实际使用软件的地方。不可避免地，在“deploy”房间也会发生一些更改。我希望两个房间在git中共享相同的历史记录。
限制：
1.由于安全原因，这两个房间没有网络连接。
2.只有文本文件（人类可读）可以离开“deploy”房间。
使用“git bundle”将更改移动到“deploy”房间很简单，并跟踪我们移动到“deploy”房间的最后一个提交。由于仅限于文本，从房间中移出更改更加困难。
目标：像“git pull”一样在我的两个未连接的房间之间来回移动提交，即在两个房间中具有相同的SHA1哈希值。
到目前为止：
限制：
1.由于安全原因，这两个房间没有网络连接。
2.只有文本文件（人类可读）可以离开“deploy”房间。
使用“git bundle”将更改移动到“deploy”房间很简单，并跟踪我们移动到“deploy”房间的最后一个提交。由于仅限于文本，从房间中移出更改更加困难。
目标：像“git pull”一样在我的两个未连接的房间之间来回移动提交，即在两个房间中具有相同的SHA1哈希值。
到目前为止：
我尝试使用
git format-patch将更改从部署移回开发，但这样做不会记录合并，因此需要为每个连续的更改集生成不同的补丁集以及一些记录如何重现恰好发生在其中的合并提交。有一些讨论关于为合并提交创建差异文件，但这似乎没有捕获实际的祖先关系，只有更改。看起来补丁可能不是提供必要信息的足够丰富的格式。可以使用一些打包到文本的脚本将包转换为非压缩和人类可读（稍微）的格式，（然后在下载后再次转换）但我没有找到任何证据表明这样的脚本存在。
也许可以编写一个脚本，从某个公共祖先到最新提交遍历历史，然后a）制作补丁或b）重新创建一些常见引用的合并。
备选方案：我可以将从部署室出来的提交压缩成一个原始补丁，并破坏历史记录，但那么从开发->部署的进一步下载将破坏任何现有的工作副本。不理想。
更新： 我相信git fast-export可以做到我需要的，虽然大多数示例是在整个存储库上工作而不是像git bundle那样部分历史记录。我有一个工作的玩具示例，可以将部分历史记录导出到过时的克隆中，但它要求我手动编辑快速导出输出，以便我添加from <sha1>到第一个提交。如果没有这个修改，导入会创建不同的sha1，然后使用Not updating refs/heads/master (new tip <hash> does not contain <master's hash>)进行投诉。
更新2：
我的git fast-export解决方案确实有效，但它存在带宽问题，因为它通过提供全新文件而不是与以前文件的差异来工作。这是不可接受的，因为我实际上必须阅读所有这些额外的行。