我可以使用 Git 在发布之间填写旧项目的更改历史记录吗？

Question

假设我们目前有一个遗留代码库正在对其进行处理，并且正在移植到新硬件上。当前版本控制仅被视为，并且对代码所做的任何工作都是通过一系列压缩包，这些压缩包一次转换为一个 CM（以及对其进行测试）。准备好发布后，各个更改将转储到先前版本之上，并解决任何冲突，然后该代码将通过此版本的回归测试套件运行，并成为新版本。

我们的 CMS 目前只有主要版本可供下拉，并且我们有单独的更改可用。我们正在讨论为新的维护周期迁移到一些 TFS-Git 混合，因为我们可以抛弃编译代码和管理更改的旧系统（我们希望使用 Git 作为开发存储库，但是因为我们'一直在使用 TFS，这就是我们将继续使用的东西（我希望那个说这句话的人正在考虑将 TFS 用于夜间和 CI，它真的不仅仅停留在维持现状））。我已经删除了所有主要版本，并将它们设置为个人仓库中的提交，然后解决这个问题，这很容易做到。

如果我想提倡使用 Git 或 TFS 作为跟踪更改的主要方法，而不是附加到 Word 文档的代码文件，我可能需要证明我们可以做到这一点。我听说我们不能离开所有更改的一个基线，并且跟踪更改的唯一方法是将实际更改的文件作为一个包上交（不能绕开我的脑袋）。实际上，很多人对为什么不能改变流程有很多不同的看法，但这将不得不与新硬件有关，我宁愿解决方案不要半生不熟。

到目前为止，我已经从 VMS CMS 中获取了所有主要版本，从 TFS 中获取了横幅文件（仅限 cmets 文件，一种在编写 SDD 的方法），当我们从 CMS 切换到这些文件时，确定了顺序它们之间的事件，并在一个主服务器上进行一系列提交，每个提交都由发布标记（将横幅版本的提交保存在 TFS 上，实际上是在两个 CMS 版本之间，我们使用的源参考驱动器显示发布的横幅没有被抓）。

我想返回并从每个标记的提交中创建一个分支，对吗？然后 rebase 所以每个都有以前的版本作为父版本？那时，为了证明可以捕获更改历史记录，我将为我们为子版本存档的每个更改包分支一个版本。然后，我会为每个更改包分支重新设置子版本。我希望它们都同时出现，因为无论好坏，这就是我们的运作方式。

所以我的树目前就是这样......

        *baseline
            |         
            |   
        *release1
            |
            |
        *release2

树看起来像这样......

        *baseline
      /     |     \
   /        |        \
*chg0-0 *chg0-1 ...chg0-n
   \        |        /
      \     |     /
        *release1
      /     |     \
   /        |        \
*chg1-0 *chg1-1 ...chg1-n
   \        |        /
      \     |     /
        *release2

我可以将我拥有的东西重塑成我想要的东西吗？可以将提交重新设置为多个父级的合并吗？我似乎能够在我在家设置的测试仓库中插入这样的历史记录，但我还没有一次搞定集成步骤。然后再次一次合并一个可能仍然可以通过。

我只有这么多时间在工作中像这样'goldbrick'，我现在正忙于编写功能包。我希望协作不仅仅是将某人指向我在网络上的共享，定期必须通过为每个软件组件设置一组 Beyond Compare 会话来进行“提交”，并转储更改的文件和差异那里。我们中只有少数人同时处理代码，但他们为这类东西制作工具......

Answer 1

我建议看看cms2git。我没有看到可下载的代码，但对所涉及的问题进行了有用的描述。