如何对 GIT 分支进行规划?

项目背景：

该项目是在2011年11月份使用Asp.net三层帮荷兰某个客户开发的机票预定系统

该客户主要是做中国与欧洲的旅行社业务，特别是最近两年由于中国的发展因此客户也越来越重视机票业务

于是他们跟去哪儿沟通并进行了合作，并我司来完成与去哪儿机票业务的对接业务

因为该客户项目从一开始就由我来负责，因此该对接业务也就自然而然的落到我的身上 

 

问题描述：

因为对接功能需要与现在的项目进行整合，因此我只是在机票预定系统的解决方案里添加了一个新项目（Qunar），并且使用Git来分别进行版本控制（2015前使用VSS，就是因为Git的分支功能）

 

后面由于去哪儿某个功能是在另一个API里实现的，而且跟对接功能也没有太大的关系，因此又将其作为一个单独的项目(QunarServices)来完成

 

在进行对接功能期间网站项目也有变更（对接功能会影响到网站后台的某个功能）

因为这三个分支实现的功能大部分是不一样的，所以我只能按不同的分支来进行管理

重点是在三个项目之间（四个分支加上master）同时进行开发，因为所有项目都使用了N个通用的项目(Model等)所以当某个分支对通用的组件项目进行了变更后，其他的三个分支也需要同步以保持一致（某些分支如果不同步可能也不会影响该分支的功能,只是三个分支通用项目进行同步）

 

关于如何合并其他分支的某些文件,我现在的处理流程是这样的：

1. 先检验当前分支与要合并分支通用文件的差异(要合并的分支必须要全部commit)
2. 拉出要“合并某分支文件有差异”的所有文件（通用项目中的文件） git checkout 分支名称 文件名 文件名
3. 添加并commit到当前分支 git commit -a -m '注释 合并其他分支的某些文件 和合并分支提交时的说明信息'

 

当通用的项目文件很少更改时，以上方案运行的不错

最近去哪儿项目正在收尾阶段，因此在对解决方案进行整合，然后我就发现三个分支里的通用项目都有差异(最近三个分支都对通用项目进行变更且没有合并)

这样就对我整合解决方案带来了很多阻力（我需要将三个分支的通用项目时行合并）

因为通用项目都只是引用了该通用项目的DLL组件而已，所以完全没有必要在每个分支里进行维护（已经从2015年初到至今）

于是我就在想是不是我的解决方案规划有问题而导致了我错误的使用了Git，但如果有问题的话我该如何规则分支和解决方案呢？

 

问题来了：如何在尽量不丢失提交历史的情况下对整个解决方案和分支进行重新规则

 

想到的解决方案：

1. 在不改变当前分支的情况下，在每个分支里将通用项目进行过滤（不删除项目文件），只将其保留master分支（master从2015后没有进行过合并，需要合并所有通用项目的提交历史大概有50+要循环以上合并流程）
2. 将通用项目从每个分支过滤，并单独作为一个单独的分支进行维护（同1类似也需要循环以上合并流程）
3. 删除所有分支并重建（不可能，有很多提交历史）
4. 其他？？

目前分支说明：

master:VSS迁移后的Web基准分支（2015年从VSS迁移后无提交）

website:基于master web项目分支

qunar2:基于master 去哪儿对接项目分支

qunarTTS:基于qunar2 去哪儿对接项目某服务分支