问题

现状：两个项目源码存在八成为同样的代码，管理在两个SVN库中。 背景：从一个SVN项目分裂成两个独立项目（PBB_2/Reader_v2）对应延伸出来SVN库，随后在两个库中开发不同的功能版本（PBB_7/Reader_v9）。
需求：现在准备将两项目中新增的功能重新合并起来，即将PBB_v7合并到Reader_v9中。 分析：需要把PBB_v3–PBB_v7的5个提交，合并到Reader_v9中

对PBB迭代的十几个版本中新增的功能涉及面太广，手动合并出错率高，协作难度大，纯劳力搬砖着实要命。 以下总结几条建议

方案一：打补丁法合并源码

注：仅适用于同一个库使用

实现步骤：

  1. git-svn命令把svn库转为git库
  2. 将5个提交重演到Reader_v9版中

重演方案：

  1. 打补丁法：通过压缩提交法把PBB_v7若干提交整合成一个提交，再创建一个补丁，重演到Reader_v9上
    1. 交互变基压缩法，压缩成一个提交
    2. reset压缩提交法，将提交压缩 git reset –soft 1bf27c6a33d87c2e36fa75431224124f91d8b482

案例：在大型项目中，贡献者常以使用补丁文件贡献代码 结论：打补丁法的前提打补丁的宿主库必须和将要应用补丁的库为同一库源。故使用版本库来合并两个独立不想关的svn库，无法通过打补丁法实现合并。

方案二：项目模块化合并

在PBB Reader中通过项目依赖整合IJK／mupdf／maker

  1. 操作
    1. 取消Maker原有IJK，mupdf的依赖
    2. 在PBB Reader中配置Maker依赖 ：隐私空间涉及到的阅读功能在Reader中实现
    3. 新需求开发
  2. 好处
    1. 源码隔离，功能共享，对现有功能的源码无要做任何修改
    2. 项目之间相互独立，便于后续拆分或整合
    3. 更多精力专注代码优化

否决方案二，采用手动合并

Reader本属于一个播放器，是从PBB应用的lite版，主要业务都是在PBB中实现的，当前需求是让PBB集成到Reader中，如何使用PBB Framework集成，需要暴漏大量的接口，业务层的高耦合性已经违背了封装原则。故作罢。

突破了合并时遇到的棘手问题，加密崩溃，最终排查出socker传输结构体导致的异常，maker和Reader之间的差异导致合并过程更加困难，最终采用对讲maker中对加密实现文件的封装，在集成到Reader中，即隔离冲突，暴露功能，程序架构集成过程中更便捷合理化。

相关知识：

引用日志： git reflog 引用日志只存在本地仓库中，只记录第一次clone到之后，在本地仓库中的操作日志，服务器端不会同步这些引用记录，所以在本地无法查看别人的引用日志。

祖先引用

几种表达式含义

  • 第一种：^/^^^(多个) HEAD^:指向祖先提交 hash值^（^^^） :指向该引用的上一个提交，几个符号就是指向上几个提交 ^数字:只适用于合并（merge）提交，有多个父提交。如：hash值^2表示第二父提交。第一父提交是指合并时所在的分支，第二父提交是指合并进来的分支。

  • 第二种：~数字 HEAD~: 指向祖先提交 HEAD~数字:指向指向上几个提交
    hash值^数字:指向该引用的上几个提交