供交流分享，写的比较仓促，假定读者有一定基础
背景
目前在一家外包业务为主的公司任职，近期因公司效益和政策原因影响，出现同事大批量离职的情况。
起因
因为交接工作比较集中，而且一个有产品理想的外包公司特点就是多项目、多版本，所以待交接内容很多，那身在一家公司的边缘（穷）开发部门，主要交接内容就是源码和文档。撇开规范性和完整性不谈，在整理离职同事的仓库和资料时，发现多个项目共用一套代码的情况非常难以理解和整理，所以萌生出了一些新的管理思路，简单推敲了一下发现基本可行，这里记录一下免得后续忘记了。
现状
目前的模式是一套源码（产品或者第一个此类业务的项目），只要新的外包项目业务一致，那么就在这个仓库中新建一个分支，在这个分支上进行新项目的定制化改动和调整。
这个模式本身是没什么问题的，最大的好处就是可以共用代码，共享bug修复和新的功能特性（即在一个项目中发生了变动，其他项目同步调整），也符合标准意义上的产品开发流程。但毕竟我们还是一家外包公司，主要业务还是在接项目->快速出活->接项目这个死循环中。
说了这么多，问题点在哪里呢，以下：
- 过多的分支会导致项目不清晰，如果非常仓促的接过来，很难快速搞清楚某个外包项目是用的哪套源码，毕竟每个外包项目的叫法也不一样；况且你每个外包分支又会有多个开发分支，你怎么区分？
- 不符合项目管理需要，在项目的Git仓库组管理模式中，一个项目会存在多个平台的源码仓库，比如一个防疫管控系统，你要有服务器，要有接口，要有移动平台，这就最少三个源码仓库。但现在的源码管理模式中，假设你的项目是脱胎于基于GIS的疫情防控平台，那么只有这个里面会存在三个仓库，其他的后续孵化项目仓库组中压根不存在这三套源码，因为都在第一个仓库进行分支管理了；你要觉得OK也没啥问题的话，是因为我举的这个例子是简化模型，假设企业健康上报平台后续新增了一个数据自动采集工具，那么企业健康上报平台仓库组现在是有一个源码仓库的是吧，你一个不了解的人接过来一看，你这个企业健康上报项目会不会就被认为是只是一个数据自动采集业务？
思路
后续发现其实走偏了，我们并不是做出一款产品服务于大众。毕竟是一家外包公司，就算做出产品推广也是各外包项目定制差异化推广，并且是按照功能点进行收费，按照工作量进行运维。那么我新功能和bug修复都是收费的，就算不特性不共享，我手动粘过来，也没有会太大工作量。我认为在外包厂的项目体量和项目严格管理标准下，这部分工作量的牺牲反而会给工作带来便利，最起码符合人的管理习惯。项目经理也会对项目资源有个整体的把控，而不是在乱七八糟的扒拉各种仓库，找分支，找代码。
后续你给钱给合同，我们继续合作，我给你运维给你加功能。你后来不给钱了，那么我也没必要让你享受运维服务，在外包思路上逻辑也是正确的。
所以具体应该怎么做呢？很简单，就是如果一个新的外包项目产生了，那么从历史仓库 copy 一份仓库就可以了，两份仓库代码独立，互相管理。就这么简单，源码在分支上遵循技术上的分支管理规范，只是做一个项目定制分支上的调整。退一步讲，你如果长时间不维护后续一把来了，我就算把新的版本粘过来，借助 git 强大的代码对比工具，理论上也可以较快的完成特性平移的。
后续
以上仅仅是理论可行，接下来还要实践后再出具体的使用结论。如果在看的你有更好思路方法，又或者知道某大厂的管理模式更科学，欢迎留言讨论
