我们假设我们目前有一个遗留代码库，正在完成工作，并正在移植到新硬件。目前，版本控制仅被视为代码，并且对代码所做的任何工作都是通过一系列zip包一次转换为CM（以及对它的测试）。准备好发布时，各个更改将在先前版本的基础上转储，并解决任何冲突，然后该代码将通过此版本的回归测试套件运行，并成为新版本。
我们的CMS目前只有主要版本可供下载，我们可以进行个别更改。我们正在谈论为新的维护周期转移到一些TFS-Git混合，因为我们可以抛弃编译代码和管理变更的旧系统（我们希望使用Git作为dev repo，但是因为我们总是使用TFS，这是我们将继续使用的东西（而且我希望那个人正在考虑将TFS用于夜间和CI，它真的不是停止维持现状））。我已经删除了所有主要版本，并将它们设置为个人仓库中的提交，现在可以解决这个问题，这很容易做到。
如果我想提倡使用Git或TFS作为跟踪更改的主要方法，而不是附加到Word文档的代码文件，我可能需要证明我们可以做到这一点。我听说我们无法从所有更改的基线移开，跟踪更改的唯一方法是将实际更改的文件作为一个包转入（无法绕过我的脑袋）那）。实际上很多人都说很多不同的事情，为什么这个过程不能改变，但它必须要用新的硬件，我宁愿解决方案不是半生不熟。
到目前为止，我已经从VMS CMS中获取了所有主要版本，当我们从CMS切换到那些时，从TFS获取了横幅文件（仅评论文件，一种滑动编写SDD的方法），确定它们之间的事件序列，并在一个主机上进行一系列提交，每个提交标记为发布（保存TFS上的横幅版本的提交，实际上是在两个CMS版本之间，我们使用的源参考驱动器显示发布＆＃39 ; s横幅没有被捕获）。
我想回去为每个标记的提交做一个分支，对吗？然后rebase所以每个都有作为父亲的前一个版本？此时，为了证明可以捕获更改历史记录，我将为我们为子版本存档的每个更改包分发一个版本。然后，我为每个更改包分支重新定义子版本。我希望他们能够同时受到影响，因为不管我们的运作方式是好还是坏。
所以我的树目前就是这个......
*baseline
|
|
*release1
|
|
*release2
树看起来像这样......
*baseline
/ | \
/ | \
*chg0-0 *chg0-1 ...chg0-n
\ | /
\ | /
*release1
/ | \
/ | \
*chg1-0 *chg1-1 ...chg1-n
\ | /
\ | /
*release2
我可以将我拥有的东西重塑成我想要的东西吗？提交可以作为多个父母的合并而重新定位吗？我似乎能够在我在家里设置的测试回购中插入这样的历史，但我还没有一次性地想出整合。然后再次合并一个可能仍然可以通过。
我只有很多时间去找金砖＆＃39;像这样在工作中，我现在忙于编写功能包。我喜欢合作不仅仅是指点某人在我的网络上分享，经常不得不做出提交＆＃34;通过为每个软件组件为该增量设置一组Beyond Compare会话，并将更改的文件和差异转储到那里。我们中只有少数人一次处理代码，但他们为这类东西制作工具......