《代码管理》

1、代码仓库

代码仓库主要有单代码仓库和多代码仓库两种解决方案

1.1、单代码仓库

单代码仓库又称为中心仓库。其主要优点如下：

• 方便代码重用
• 方便代码重构
• 统一开放规范
  目前很多大的互联网公司，均采用单代码仓库的策略。典型的如Google公司。

但是单代码仓库也有很多弊端，如：

• 权限管理比较麻烦
• 代码量过多，需要开发专门的系统去管理仓库。

1.2、多代码仓库

多代码仓库，将代码拆分成多个仓库，利用分治的思想管理代码。其主要的构建原则是：

• 每个仓库可以独立编译交付，或者作为服务独立部署。
• 不同的开发语言，尽量不要放到同一个仓库。

1.3、代码仓库优化

当仓库中出现大量的文件，尤其是二进制的非文本文件。会极大的影响传递的效率，因此需要对仓库进行适当的优化。

项目中的大文件主要分为以下几类：

1.3.1、资源和文档

比如SRS、数据库文档、用户提供的资料、项目参考的资料等等。这些文件其实并不是代码的一部分，不建议放在代码仓库中。应建立项目级的wiki，存放这些资料。

1.3.2、依赖文件

比如需要引用的第三方dll文件，jar包等。这类文件可以通过依赖管理系统去单独管理。

1.3.3、配套文件

比如图片、配置文件、数据文件、模板文件等等。这些文件可以通过Git LFS系统管理。（没有使用经验，也不知道是什么）

2、分支策略

2.1、简单分支

对于小型开发团队来说，最适合使用的是简单分支策略。
开发人员为某个功能创建一个独立的分支，在功能分支上，提交未完成的编码。
完成的代码，合并到主分支上。
建立版本分支，将需要发布到生产环境的代码，合并到版本分支里面。

2.2、多产品线困境

多产品线，指的是同一个产品，由于不同的用户需求，产生了不同的版本。比如PDMS插件中，12.0版本和12.1版本，就是多产品线。可能主要逻辑相似，但部分写法会有差异。

书中推荐了4种方案解决这个问题，综合看下来，使用fork的方案最适合。感觉还是不能解决问题

3、依赖管理

3.1、依赖地狱

不合理的依赖，会形成依赖的地域，主要表现在以下几个方面：
依赖层次过多
循环依赖
依赖冲突
无法向下兼容

3.2、依赖类型

依赖主要分为源代码依赖和二进制依赖。例如PDMS插件中，调用的pmlobj，属于源代码依赖。这些对象文件不需要编译即可使用。而加载进内存的DLL文件则属于二进制依赖，需要预先编译。

3.3、语义化版本

主版本.次版本.修订号

命名原则：

• 从0开始，逐渐加1递增。不要用0补全，应使用1，而不是01。
• 当次版本升版的时候，修订号清零。
• 当主版本升版的时候，次版本和修订号清零。
• 当处于开发阶段的时候，版本以0.xx.xx的形式表达。
• 第一个发行版本，应以1.0.0作为正式的版本号。

升版规则：

• 修订号，程序修正了bug时升版。
• 次版本，程序新增了功能，同时做了对外的兼容时升版。比如程序增加了新的功能，但- 并没有减少或修改已有的接口。不会对依赖本程序的其他程序照成影响。
• 主版本，程序做了不对外兼容时升版。比如删除了某些接口，或者变更了现有接口的使用方法。这些更改会影响依赖本程序的其他程序。