开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：源代码管理及软件配置（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1270
源代码管理及软件配置（一）
内容介绍
一、代码讲解
二、Commit 讲解
三、无效 commit 产生的原因
四、疑问讲解
五、课后总结
一、代码讲解
（1）代码的作用
在软件交付运行过程中，认为是以代码为中心的交付过程，其中代码的作用，第一是保存在交付运行中的交付制品及通过代码所描绘的最终产物，代码所定义的，如系统如何工作，软件如何交付，以及交付的环境。都是围绕代码所运行。另外代码是维护团队合作的东西工具，代码的写入重要目的是为了人来进行读取，作为程序员需要回到源头代码。
（2）代码举例说明
如下图为某个公司团队的代码结构，risk-management 为代码组，
下属 qinglong 为子代码组，而其下属的 aTeam 又是一个子代码组，
会发现存在多个层次的代码组，如 docs 等同时代码组包括很多东西，如 risk-service android-sdks 以及 data-docs 多个代码库以及代码组，该架构可以反映在代码组织结构的相关问题:
比如说第一个在最上层 risk-mangement 是一个系统叫风险管理，而子目录叫qinglong，不知道是一个团队还是应用，其余下属子目录玄武、docs 既有中文有存在英文，所以代码的命名方式混乱。
第二个在 android-sdks 存储很多二进制文件，而在代码库存储是一种消耗极大且不合理的方式。
第三个 aTeam 存在data-model而其余同一归属则存在玄武所属下，如 data-console、data-task，大概率属于同一应用或产品的存在于不同层级，十分奇怪。
再往下为 common-lib,是一个公共库，但该方式感觉只为玄武公共，所以十分奇怪，此外在 docs 下存在 risk-docs、data-docs 一个为针对风控一个则为针对数据，其中文档和业务为分开存放，所以十分奇怪。
综上存在上述问题，及在平时代码设置所涉及到，在此假设所有代码都存在一个代码库，且所有人均可访问，如何设置代码。
（3）代码组织方式
参考组织方式，代码可以进行分组，代码组对应一个代码库，最终相当于一个大库。当然并不是组合成一个大库，而是这样的一个思路，如假设只存在一个代码库，此时的组织方式必然不同。
所以现在并不使用大库而是选择该思路进行使用，现在代码组，子代码组和代码库组合在一起，本质上为形成大库，本质上是组合成大库的形式，是将很多Git代码库和代码组形成实际上的概念。
代码组(+子代码组)+Git 代码库=大库
接下来案列讲解，针对上述问题合理的代码组织方式，作为一个系统下属俩个应用为risk和data，每个应用下面下属文档和服务，此外存在公共的 common，被所有的应用所依赖的。所以首先将所属于同一应用的服务放置在一起，此外将 common放置到正确位置，如果这样便是和行程跟进，不是根据团队进行划分，而是按照应用组进行划分这样比较清楚
（4）总结建议
进行总结，提供实践建议，首先对于考虑代码库的内容和生产原代码就是生产代码，另外文档、测试等相应的业务可放置到相应的应用组下，此外注意不可以将二进制文件放到代码库中，因为二进制文件本身容量大、小文件多、无法追溯，此外代码库的组织结构应按照系统、应用和模块等层次来组织代码库，每一层的所属内容应划分清晰。另外注意代码库的可见性，通用的代码库放在其通用级别都可以访问的位置，比如说 common，因为共用代码库所有人都可以依赖和发起需求，放置共用可以更方便供他人修改使用，此外除核心算法等少数代码除外尽量将代码库的访问在同一系统/应用向有关人员公开，可以更全面的清晰代码的容貌，可规避相关风险。
实践建议
代码库的内容:
.软件的源代码(Production Code)将文档(和测试)的 git 库放到其相关
应用组下不要将制品(如系统二进制包)保存
在代码库中
代码库的组织结构:
按照系统、应用和模块的层次来组织
代码库
同一个系统/应用层级的所有内容位于
同一个代码组下代码库的可见性:通用代码库放在其通用级别都可以访问的位置
除核心算法等少数代码除外尽量将代码库的访问在同一系统/应用向有关人员公开
二、Commit 讲解
软件交付过程，其本质使开发者围绕代码库的协作过程一切皆 Commit。
如代码的提交等本质皆是 commit，所以说软件交付过程，其本质使开发者围绕代码库的协作过程，以下例子存在 branch、master、brach 等操作其本质也均是围绕commit 展开的。
提供以下三点讲解，及 SMALL、LINEAR、TOMIC。
SMALL
一个应用一个 Git 仓库，尽可能小不要大，因为维护时成本巨大
不在Git上存储构建产物和其他二进制文件，以前的同学是为了方便，但操作并不妥，所以建议构建产物放到专有位置，不然很难知道产物是之前的构建代码还是现在的代码所产生的，难以追溯。
LINEAR
及线性，多用 rebase，少用 merge
避免无效 commit，比如说有些很长但80%都是无效的，不知道在干什么，而且并不完整
TOMIC
保证原子性，一个 commit 解决一个问题，比如说添加一个功能，就这个是非常明确的或加了个 API，问题尽可能小，不能很大比如说写了两千行代码提交一个file此时是很危险的因为对开发者来讲，你的比较好的情况就是很快速的有一个阶段性的成果，并且能持续有反馈，持续的往目标去贴近它。 但如果说前面憋了很久，一直也不知道怎么样，最后一把搞定，其实对开发者里面觉得体验是不太好的，而且协作上来讲也不好，因为别人不知道你做多少了，对这是非常危险的，所以问题要尽可能的小。那通过 sla 三个字母，然后帮助快速记忆一下。
三、无效 commit 产生的原因
平时其实也会常常看到很多的白模式，比如说刚才提到的 mord 和 commit。
第一个问题就是说在几乎所有公司里面就随便拉开一个代码会发现有这么多自己和自己的本地和远程的这种情况，这个就是本来有 commit 处理的，结果就导致很多无效的 commit，而这种可能在 commit 之后，会对 commit 的追溯能力产生很大的影响。
然后第二个就是 commit 很多，有些人其实模拟的 commit 一下子过来3000行代码，完全找不着想干什么，所以这个是非常危险的。
第三个就是半成品的 commit，可能就半成品，比如说我要去吃饭了，不管先提交一把，可能这个代码连那个编译都过不了，那这个其实是不好的，没有任何意义，对最后一个就是分支间的相互合并这，比如说这个 master 到 dylp 要互相合来合去。
一旦这种合并一多之后，就会发现那个 commit 的追溯就很难，而且很有可能出问题，就是不知道谁是语言，应该有一个主唯一的主干或者说一个明确的主干，往那边去合或从那边来，而不应该说是互相的磨叽。 就如果频繁的有这种互相的磨叽，是要注意警惕的一个，这个可以放到一个分析模式，然后采取一下。这是常常了解到的一个源代码的一个管理的一个过程。
