问题在于：在工作中我们有一些旧的和糟糕的SVN回购。他们中的大多数都来自更老的CVS回购。无法知道哪个分支是最后一个，多年来没有在主干中提交（字面意思），一些库在几个回购中重复...整个事情是一个巨大的混乱。
我确信这家伙应该是技术领先者，转而使用干净的git解决方案。 当然，我是指定的人。 我们将旧的SVN保留在某处，以防我们需要搜索旧的提交，因此无需转换repo并将SVN历史记录保存到git中。 这个想法真的是为了让事情干净利落。
该项目相当大，约有250万行。 它主要包括：
我读了一些关于分支策略，子模块和东西的东西，但是当谈到将理论应用于大的真实事物时，这并不容易处理...... 分支策略为something like this。
我想到了两个解决方案： - 一个用于windows exe的repo，一个用于linux exe，另一个用于库。最后一个repo将被其他两个子模块引用为子模块。 - 每个和lib一个回购。对我来说看起来有点矫枉过正，我想这需要很多脚本才能让你感到舒服。另一方面，它使每个二进制文件的版本号更加容易。
将我的项目映射到git repos的最佳策略是什么？ 如何将分支策略与子模块混合使用？
一些提示：
修改
基本上，所有可执行文件都依赖于几个库。 目前，可执行文件由OS发布。例如，如果在linux exe中添加了一个功能，那么将修改一些lib和exe，并且将释放所有linux exe并将其传递给客户端。这样，所有可执行文件都将包含相同的版本号，对应于基于SVN标记的linux部分。如果在项目的Windows部分没有修改，它就不会被释放。
构建系统是基本的：linux部分在repo的根目录下有一个makefile，然后每个exe / lib都有自己的子目录和自己的makefile。一切都是为了发布而建造的。 在Windows方面，我们有一个Visual解决方案，包含所有需要的库和可执行文件作为项目，所以一切都是构建的（但版本号是手动设置的）。
QA在这里只是一个梦想。 每个发布的都由开发人员（快速）测试，然后由客户端进行测试（有时会跳过客户端测试！）。