Git 分支策略与submodule对分支策略的影响

当前的分支策略：

1. 在master上进行主要的功能开发，功能开发完成后修改完大部分bug之后，从当前master分支上切出preRelease分支；
2. 在preRelease上继续修改bug，在master分支上开始做新需求，这两个是并行的；
3. 在preRelease修改bug完成之后，发布到市场，然后将preRelease分支合并到Release分支和master分支，删除preRelease分支；

引入submodule出现的问题：

• Release 分支的目的是为了防范线上版本出现问题，能够迅速找到对应节点的代码，修复bug，重新上线紧急版本。但是实际操作可能会出现一个问题，我们拉取了线上版本对应节点的代码，但是与submodule相关的部分却报错，因为submodule也在不停地修改中，而线上版本节点对应的submodule节点（包括branch和commit点)，我们并不知道。

如何解决这个问题：

• 使用cocoapods管理submodule，submodule如果有修改，要即使修改podspec的版本号，并且在主项目的podfile中要规定好正确的submodule版本号；这种方法能很好的管理版本之间的依赖关系，但是如果对于submodule需要频繁更新的情况，效率是不太高，而且略繁琐。
• 手动记录对应线上版本节点对应的submodule的节点；这个方法有点傻，但实施起来是最简便的。
• 其他方案

为什么之前修改过的问题后面还是会出现/为什么merge代码可能也需要多人一起并且很久：

1. 这个问题可能是出在 “preRelease分支合并到master分支”这个步骤上；
2. preRelease和master是并行开发，合并的时候，主项目的代码和submodule的代码都可能不一样了；假如有一个submodule是蓝牙模块，在preRelase分支上修改bug时对蓝牙模块做了修改，在master分支上适配新的蓝牙协议也对蓝牙模块做了修改，而主项目上的代码很多也都依赖了蓝牙模块，所以也会有很多不同（我们先不考虑主项目上其他需求的新代码和修改bug的新代码）。这个时候，如何做合并？谁来做合并？怎么做取舍？要花费多少时间？如果在时间快和代码稳健上选一个，选哪个？
3. 很多时候，我们是选择节省时间（虽然最终是否真的节约了时间先不说，但肯定是节约了merge代码的时间）。出现冲突时，一般情况是优先保证master分支新功能的代码。原因是新功能的代码多，逻辑也会复杂一些，而主观上我们会认为preRelase分支上只留有一些小bug。这样，我们按照这个逻辑，保证项目能够编译通过，merge就算结束了。
4. 但这样其实是有隐患的，preRelase分支上的部分bug可能还在。
5. 如果要解决这个问题，我们应该怎么做？那就只能花时间。首先merge时，不能使用快速合并，找到master分支功能的开发人员和修复bug的开发人员，一个一个对增、删、改的代码进行取舍，这期间需要对代码逻辑、业务逻辑等进行讨论，然后选出合适的方案。在这期间，最坏的情况是master分支和preRelase分支上某一个逻辑是对立的，必须舍弃掉一方的代码，也就是说这一方需要重新写这一部分的代码。所以，我们是选这种方案，还是直接快速合并，后面如果遇到了问题，再修改呢？
6. 还有一点要注意的是，无论选择哪种方案，我们的代码合并都应该先是从submodule开始的。也就是说一开始我们从master切preRelease分支的时候，也应该给蓝牙模块切一个ble-preRelease分支。然后合并的时候，先合并蓝牙模块的代码，再合并主项目代码。这样一来，如果子模块一多，切preRelase分支，以及修改完bug的合并，不仅步骤繁琐，而且逻辑也并不算清晰，应该怎么解决呢？是这种分支策略不合适吗？
7. 对于submodule的定义是不是有问题呢?是不是submodule得是稳定的，不需要更新的？还是说不应该选择这种并行开发的策略？还是说有更好的分支策略？还是说现在的方法就挺好的,也不需要改什么？