git
Git是一个开源的
分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件
Gitlab 可以做什么
- Gitlab 是 Git 服务端的集成管理平台，提供了：
- 代码托管服务
- 访问权限控制
- 问题跟踪，bug的记录、跟踪和讨论
- Wiki，项目中一些相关的说明和文档
- 代码审查，可以查看、评论代码
- 持续集成
issue
issue是项目管理中的重点，主要包括以下功能：
- 用于登记bug与需求
- 可以按照issue类型不同打上不同的tag
- 每个issue在每个project中有唯一的id
- 项目负责人可以@相应的开发进行开发
- 在经过单元测试和code review后，如果功能点符合，可以关闭相应的issue
- 可以通过gitlab的web界面进行相应的分析，比如按照tag和assignee进行筛选
commit
commit message可以用于追踪问题，所以
对于Git的commit的message，尽量详细的说明本次提交主要干了什么，是fix 什么bug，开发什么特性，还是update 某个功能点，这同样有助于进行code review
Git 使用原则
- 不建议留任何未提交文件就去拉取，fetch也好，不要贪拉
- 拉取不成功，解决冲突，提交不成功，解决冲突，解决不了冲突，请联系队友
- commit 写好注释
Git tips
#查看提交暂存区和版本库中文件的差异
git diff--cached
gitlog --stat #查看简单的diff结果，可以加上--stat参数
git tag -a v1.4 -m 'my version 1.4'
git log --oneline
#放弃工作区的修改
git checkout
#存储当前的修改，但不用提交commit
git stash
# 切换到Master分支
git checkout master
# 对Develop分支进行合并
git merge --no-ff develop
#删除feature分支：
git branch -d feature-x
#删除远程分支：
git push origin --delete
一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。
[git 版本管理]http://www.ruanyifeng.com/blog/2012/07/git.html
共同的事
分支管理策略
一、主分支 Master
首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。
master分支上存放的应该是随时可供在生产环境中部署的代码，它承担的责任就是：仅在发布新的可供部署的代码时才更新到master分支上的代码。当开发活动告一段落，产生了一份新的可供部署的代码时，master分支上的代码会被更新。同时，每一次更新，最好添加对应的版本号标签（TAG）。
二、开发分支 Develop
主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。
develop分支是保存当前最新开发成果的分支，它承担的责任就是功能开发完毕等待最后QA的验收，通常这个分支上的代码也是可进行每日夜间发布的代码。当代码已经足够稳定时，就可以将所有的开发成果合并回master分支了。
三、临时性分支
除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。：
辅助分支是用于组织解决特定问题的各种软件开发活动的分支，它的生存周期伴随着它的功能完成而消失。辅助分支包括
- 功能（feature）分支
预发布（release）分支
修补bug（fixbug）分支
这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。
四、功能分支
第一种是功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。
功能分支的名字，可以采用feature-*的形式命名。
创建一个功能分支：
# 这里x可以定义为自己名字的缩写，比如hxg
git checkout -b feature-x develop
开发完成后，将功能分支合并到develop分支：
git checkout develop
git merge --no-ff feature-x
删除feature分支：
git branch -d feature-x
五、预发布分支
第二种是预发布分支，它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。
预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。
创建一个预发布分支：
#这里版本号可以定义为3位，
git checkout -b release-1.2 develop
确认没有问题后，合并到master分支：
git checkout master
git merge --no-ff release-1.2
# 对合并生成的新节点，做一个标签
git tag -a 1.2
再合并到develop分支：
git checkout develop
git merge --no-ff release-1.2
最后，删除预发布分支：
git branch -d release-1.2
六、修补 bug 分支
最后一种是修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。
修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。
创建一个修补bug分支：
git checkout -b fixbug-0.1 master
修补结束后，合并到master分支：
git checkout master
git merge --no-ff fixbug-0.1
git tag -a 0.1.1
再合并到develop分支：
git checkout develop
git merge --no-ff fixbug-0.1
最后，删除"修补bug分支"：
git branch -d fixbug-0.1
工具：
TortoiseGit,SourceTree
持续集成
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
- 快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
- 防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
[Gitlab-CI]是GitLab Continuous Integration（Gitlab持续集成）的简称。
从Gitlab的8.0版本开始，gitlab就全面集成了Gitlab-CI,并且对所有项目默认开启。
只要在项目仓库的根目录添加.gitlab-ci.yml文件，并且配置了Runner（运行器），那么每一次合并请求（MR）或者push都会触发CI [pipeline]
Gitlab-runner
Gitlab-runner是.gitlab-ci.yml脚本的运行器，Gitlab-runner是基于Gitlab-CI的API进行构建的相互隔离的机器（或虚拟机）。GitLab Runner 不需要和Gitlab安装在同一台机器上，但是考虑到GitLab Runner的资源消耗问题和安全问题，也不建议这两者安装在同一台机器上。
Gitlab Runner分为两种，Shared runners和Specific runners。
Specific runners只能被指定的项目使用，Shared runners则可以运行所有开启Allow shared runners选项的项目。
GitLab-Runner就是一个用来执行软件集成脚本的东西。你可以想象一下：Runner就像一个个的工人，而GitLab-CI就是这些工人的一个管理中心，所有工人都要在GitLab-CI里面登记注册，并且表明自己是为哪个工程服务的。当相应的工程发生变化时，GitLab-CI就会通知相应的工人执行软件集成脚本。如下图所示：
stages:
- build
Job:
stage: build
only:
- develop
- master
script:
- echo "aa"
.gitlab-ci.yml 是配置CI用你的项目中做哪些操作， 这个文件位于仓库的根目录。
https://gitlab.com/gitlab-org/gitlab-ci-yml
Pipelines
Pipelines 是定义于.gitlab-ci.yml中的不同阶段的不同任务，里面可以包含多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。
任何提交或者 Merge Request 的合并都可以触发 Pipeline，如下图所示：
+------------------+ +----------------+
| | trigger | |
| Commit / MR +---------->+ Pipeline |
| | | |
+------------------+ +----------------+
我把[Pipelines]理解为流水线，流水线包含有多个阶段（stages），
Stages
Stages表示构建阶段，说白了就是上面提到的流程。我们可以在一次 Pipeline 中定义多个 Stages，这些 Stages 会有以下特点：
- 所有 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始
- 只有当所有 Stages 完成后，该构建任务 (Pipeline) 才会成功
- 如果任何一个 Stage 失败，那么后面的 Stages 不会执行，该构建任务 (Pipeline) 失败
因此，Stages 和 Pipeline 的关系就是：
+--------------------------------------------------------+
| |
| Pipeline |
| |
| +-----------+ +------------+ +------------+ |
| | Stage 1 |---->| Stage 2 |----->| Stage 3 | |
| +-----------+ +------------+ +------------+ |
| |
+--------------------------------------------------------+
每个阶段包含有一个或多个工序（jobs），比如先购料、组装、测试、包装再上线销售，每一次push或者MR都要经过流水线之后才可以合格出厂。而.gitlab-ci.yml正是定义了这条流水线有哪些阶段，每个阶段要做什么事。
Jobs表示构建工作，表示某个 Stage 里面执行的工作。我们可以在 Stages 里面定义多个 Jobs，这些 Jobs 会有以下特点：
- 相同 Stage 中的 Jobs 会并行执行
- 相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功
- 如果任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 失败
所以，Jobs 和 Stage 的关系图就是：
+------------------------------------------+
| |
| Stage 1 |
| |
| +---------+ +---------+ +---------+ |
| | Job 1 | | Job 2 | | Job 3 | |
| +---------+ +---------+ +---------+ |
| |
+------------------------------------------+
端到端部署
https://v.qq.com/x/page/z03959pwc0r.html
http://115.28.84.155/org/index.do
http://123.56.64.36:9000/projects
http://115.28.86.238/
随着新业务的增加和老业务的不断优化，项目中的代码也在一直增加，当代码量达到几十万行的时候，人工审查肯定会费时费力，所以有了 SonarQube代码质量管理平台，通过配置审查规则，让程序帮你检测代码中潜在的bug，让耗时操作通过机器完成，节约人力成本
sonarQube能带来什么？
1.Bugs和漏洞
检测代码中的bug和漏洞
2.坏味道
检测代码中潜在的错误
3.重复
显然程序中包含大量复制粘贴的代码是质量低下的 sonar可以展示源码中重复严重的地方
4.结构
检测代码行数，代码的组成成分，和占用的百分比
5.注释量
检测代码注释的量
6.依赖关系
项目结构
