第六章：代码库管理

0.0.0.0.1 基本功能

创建代码仓库分组和仓库，同时支持各类权限授权管理，实际这些代码库的初始化动作，并不需要人为的操作而来，可以考虑从DevOps系统在需求任务分配计划阶段就选择相对应的模板信息，然后一键生成所需要的基础代码库信息资源，包括仓库的初始化语言，代码基础的模板框架内容，扫描规则，构建及部署的流水线，选择部署的方式和环境信息等，在第一步就可以完成项目的走向。

0.0.0.0.2 分支管理

一个优秀的团队第一步就得有完美的代码管理模式，其中分支管理尤为重要，良好的分支结构，不仅提高开发效率，而且保证各个版本发布和上线的代码没有遭受污染，有条不紊，代码严禁，出现问题概率极低，修复问题时快速准确无误。

git flow分支模型

1.基本的Develop 和 main 分支初始化

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

#可以使用git flow 插件进行初始化分支结构
$ git flow init
Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [main]
Branch name for "next release" development: [develop]


How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

$ git branch
* develop
 main

2.创建独立功能的特性分支开发

1
2
3
4
5
6
7
8

$ git checkout develop
$ git checkout -b feature_branch
# 使用git-flow插件
$ git flow feature start feature_branch

# 完成特性分支开发后进行合并到开发分支进行测试操作
$ git checkout develop
$ git merge feature_branch

3.进行版本发行操作

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 创建relase分支
$ git checkout develop
$ git checkout -b release/0.1.0

# 使用git-flow插件
$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'

# 完成relase分支发布后合并到主干分支
$ git checkout main
$ git merge release/0.1.0

# 或者使用git-flow插件
$ git flow release finish '0.1.0'

4.最后线上问题修复操作

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 从主分支拉去修复分支
$ git checkout main
$ git checkout -b hotfix_branch

# 完成问题修复后要记住合并到主干分支和开发分支，保证修复的代码与接下来的版本保持一致。
$ git checkout main
$ git merge hotfix_branch
$ git checkout develop
$ git merge hotfix_branch
$ git branch -D hotfix_branch # 删除已经修复合并后的fix分支

Aone flow分支模型

AoneFlow模型更加适合敏捷迭代开发，更加灵活和同时具有其他分支模型功能，它基本上兼顾了 TrunkBased 的“易于持续集成”和 GitFlow 的“易于管理需求”特点，同时规避掉 GitFlow 的那些繁文缛节。

AoneFlow 只使用三种分支类型：主干分支、特性分支、发布分支，以及三条基本规则。

1.从主干创建特性分支

每个工作项（可以是一个人完成，或是多个人协作完成）对应一个特性分支，所有的修改都不允许直接提交到主干。

2.通过合并特性分支，形成发布分支

AoneFlow 的发布分支设计十分巧妙，可谓整个体系的精髓。GitFlow 先将已经完成的特性分支合并回公共主线（即开发分支），然后从公共主线拉出发布分支。TrunkBased 同样是等所有需要的特性都在主干分支上开发完成，然后从主干分支的特定位置拉出发布分支。而 AoneFlow 的思路是，从主干上拉出一条新分支，将所有本次要集成或发布的特性分支依次合并过去，从而得到发布分支。发布分支通常以release/前缀命名。

3.发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支。

当一条发布分支上的流水线完成了一次线上正式环境的部署，就意味着相应的功能真正的发布了，此时应该将这条发布分支合并到主干。为了避免在代码仓库里堆积大量历史上的特性分支，还应该清理掉已经上线部分特性分支。与 GitFlow 相似，主干分支上的最新版本始终与线上版本一致，如果要回溯历史版本，只需在主干分支上找到相应的版本标签即可。

0.0.0.0.3 代码质量

很多代码库在日常的管理和开发中，时不时会为了开发快速，而忽略了代码的质量，其中代码质量包括，静态代码质量：代码缺陷，漏洞，重复率，技术债务，覆盖率等。代码安全扫描：代码中包含的依赖或者代码不安全问题。单元测试覆盖率：可以单独作为开发对自己代码覆盖测试的标准。整个过程会提升代码质量。

0.0.0.0.4 代码评审

为了更好的支持团队多人协助开发，同时保证代码提交的第一关质量保证，因此需要进行代码合并评审操作，就是由开发人员写好代码后，发起一个合并评审请求，再由开发负责人或者其他开发成员进行code review，没有问题的情况下进行代码合并。

0.0.0.0.5 代码钩子

当需要根据代码提交或者合并时候做出的额外的动作时，这时候web hook就很有用处啦。提交代码或合并的时候触发一些列流水线或者检查校验动作，目的为了减少开发成员人为参与和遗漏操作，同时保证代码库在整个开发环节都会涉及所有必要操作都参与操作。例如：jira任务调度，Jenkins流水线操作调度，提交信息校验等。