7

我有两个房间,我在其中使用 git 维护一些源代码,一个“开发”房间,其中大多数开发发生在一个“部署”房间,我们实际使用该软件。不可避免地,部署室也会发生一些变化。我希望两个房间在 git 中共享相同的历史记录。

限制:

  1. 出于安全原因,这两个房间没有网络连接。
  2. 只有文本文件(人类可读)可以离开部署室。

使用 将更改移动到部署室很简单git bundle,并跟踪我们移动到部署室的最后一次提交。由于仅限文本的限制,将更改移出房间更加困难。

目标:在我的两个未连接的房间之间来回移动提交,就好像git pull发生了一样,两个房间中的 SHA1 哈希值相同。

至今:

  • 我试图git format-patch将更改从部署移回开发,但这不会记录合并,因此需要为每个连续的更改集生成不同的补丁集以及如何重现确切的合并提交的一些记录发生在两者之间。有一些关于为合并提交制作差异的讨论,但这似乎并没有捕捉到实际的祖先,只有变化。看起来补丁可能不是一种足够丰富的格式来提供必要的信息。

  • 一些捆绑到文本的脚本可用于将捆绑转换为非压缩和人类可读(ish)格式,(然后在下载后再次返回),但我没有发现存在这样一个脚本的证据。

  • 也许可以编写一个脚本来将历史从某个共同的祖先走到最新的提交,然后 a) 制作补丁或 b) 重新创建一些众所周知的 ref 的合并。

回退: 我总是可以将来自部署室的提交压缩到一个原始补丁中并破坏历史记录,但是从 dev->deploy 进一步下载会破坏任何现有的工作副本。不理想。

更新: 我相信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解决方案确实有效,但存在带宽问题,因为它通过提供全新文件而不是与以前文件的差异来工作。这是不可接受的,因为我实际上必须阅读所有这些额外的行。

4

1 回答 1

5

我从未找到完美的解决方案,但我们现在所做的似乎奏效了。主要缺点是部署室中的提交最初有一个 SHA1,然后在与开发室合并后更改为另一个 SHA1。好消息是git很容易识别它们,因为相同的提交可以merge直接通过它们。

  • 我们必须跟踪 3 个检查点:
    • dev/master在开发室有最新的发展。
    • deploy/master在部署室中具有最新的发展。
    • dev_deploy_common这是两个历史共享的最后一次提交。

.

  1. 当我们将代码从开发移动到部署时(使用捆绑包),我们将提交作为部署室(进入)dev_deploy_common内的分支的一部分,然后从那里执行并解决和冲突。git pulldev_deploy_commondeploy/mastergit merge dev_deploy_common

  2. 当我们将代码从部署移动到开发(必须是文本文件)时,我们会执行一些额外的步骤:

  3. 首先,我们重新定位deploy/masterdev_deploy_common以便我们所有的补丁都是连续的。这通常很容易,因为我们已经处理了在将包从开发人员带到部署时发生的合并期间的任何冲突。

  4. 其次,我们使用生成补丁集

    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补丁的集合。该文件可以进行人工审核,然后移至开发室。

  5. 在开发室中,我们使用以下命令导入补丁集:

    git am -k -3 --keep-cr --committer-date-is-author-date patchset.txt
    

    不幸的是,尽管我们使用了所有可以保持补丁完全相同的命令,但一些属性发生了变化,主要是提交者。因此,“相同”的提交将在开发室和部署室中具有不同的 SHA1。这种差异将持续存在,直到我们将捆绑包移回部署室。

  6. 当将一个包从开发移动到部署时,该merge操作(通常)识别相同的补丁并无缝地用开发历史中的补丁替换提交。请参见步骤 1。

于 2016-10-18T15:52:56.153 回答