我有两个房间，我使用git维护一些源代码，大多数开发发生的“开发”房间和我们实际使用软件的“部署”房间。部署室中也不可避免地发生了一些变化。我希望两个房间在git中分享相同的历史。
限制：
使用git bundle将更改移动到部署室很简单，并跟踪我们移入部署室的上次提交。由于纯文本限制，将更改移出房间更加困难。
目标：在两个未连接的房间之间来回移动提交，就好像git pull已经发生一样，即，两个房间都有相同的SHA1哈希。 / p>
到目前为止：
我已经尝试git format-patch将更改从部署移回dev，但这不会记录合并，因此需要为每个连续的更改集生成不同的补丁集以及一些记录如何重现之间发生的确切合并提交。有一些讨论about making diffs for merge commits，但这似乎并没有捕捉到实际的祖先，只有变化。补丁似乎不是一种足够丰富的格式来提供必要的信息。
可以使用一些bundle-to-text脚本将包转换为非压缩和人类可读（ish）格式（然后在下载后再返回）但我没有发现这样的证据脚本存在。
也许可以编写一个脚本来将历史从一些共同的祖先传递到最新的提交，并且a）制作补丁或b）重新创建一些众所周知的引用的合并。
后备：我总是可以将来自部署室的提交压缩成一个原始补丁并打破历史记录，但是从dev-＆gt;部署进一步下载会破坏任何现有的工作副本。不理想。
更新的
我相信git fast-export可能会做我需要的，尽管大多数示例都使用它来处理整个存储库而不是像git bundle这样的部分历史记录。我有一个工作的玩具示例，我可以将部分历史记录导出到一个过时的克隆，但它需要我手动编辑快速导出输出，以便我在第一次提交时添加from <sha1> 。如果没有此修改，导入将创建不同的sha1，然后使用Not updating refs/heads/master (new tip <hash> does not contain <master's hash>)进行投诉。
UPDATE2：
我的git fast-export解决方案确实有效，但它有带宽问题，因为它通过提供全新文件而不是以前文件的差异来工作。这是不可接受的，因为我实际上必须阅读所有这些额外的行。
答案 0 :(得分：5)
我从未找到完美的解决方案，但我们现在所做的似乎也有效。主要缺点是部署室内的提交最初有一个SHA1，然后在与开发室合并后更改为不同的SHA1。好消息是git很容易识别它们，因为相同的提交可以merge通过它们。
dev/master在开发室中有最新开发。deploy/master，它在部署室中有最新的开发。dev_deploy_common这是两个历史记录共享的最后一次提交。。
当我们将代码从dev移动到部署（使用bundle）时，我们将提交作为部署室dev_deploy_common内git pull分支的一部分进入dev_deploy_common }），然后从deploy/master执行git merge dev_deploy_common然后解决并发生冲突。
当我们将代码从deploy移动到dev（必须是文本文件）时，我们会做一些额外的步骤：
首先我们将deploy/master重新绑定到dev_deploy_common，以便我们所有的补丁都是连续的。这通常很容易，因为我们已经处理了在将捆绑从dev部署到部署时发生的合并期间的任何冲突。
其次，我们使用
生成补丁集git format-patch -M25 -C25 --find-copies-harder -k --ignore-if-in-upstream
-M25 -C25 --find-copies-harder选项只会减小输出文本大小。 -k选项使提交主题保持不变。自--ignore-if-in-upstream以来，dev_deploy_common将我们的提交限制为新的提交。
结果是patchset.txt个补丁集合。可以对此文件进行手工审核，然后将其移至开发室。
在开发室中，我们使用以下命令导入补丁集：
git am -k -3 --keep-cr --committer-date-is-author-date patchset.txt
不幸的是，即使我们使用所有命令来保持补丁完全相同，但一些属性会发生变化，主要是提交者。因此，＆＃34;相同＆＃34; commit将在开发和部署室中具有不同的SHA1。这种差异将一直存在，直到我们将一个捆绑回到部署室。
将包从dev移动到部署时，merge操作（通常）会识别相同的修补程序，并使用dev历史记录中的提交无缝替换提交。见步骤1.