Git Work Flow

什么是GitLab

GitLab是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的Web服务，可通过Web界面进行访问公开的或者私人项目。它拥有与GitHub类似的功能，能够浏览源代码，管理缺陷和注释。

Git的特点

分布式
按元数据方式存储
分支
全局版本号
内容完整性

为什么使用GitLab

1. 对比其他同类竞品
   禅道、teambition等项目软件，使用太复杂，培训成本太高，另外都付费。
   SVN 部署麻烦，不存在项目进度控制。
   Github 免费不提供私有库，另外没法进行精确权限控制，无法满足企业私密和安全需求。
   GitLab 免费，不需要部署，操作简单，可以流水线和项目进度协作，私有库满足安全性和私密需求。
2. GitLab的好处
   （1）所有人想看三个月前的某个版本都很容易看到。
   （2）清晰的项目管理和责任明确，产品延迟上线原因很明确。比如产品确实没上线可是一个月产品的版本迭代了4次，文档超过10万字，这说明工作量太大制定计划不合理。通过燃尽图可以清晰的知道团队的状态。
   （3）清晰的看到产品迭代，为产品研发提供参考。
   （4）作为最大和程序员首选平台，使用这个平台有利于销售和运营了解我们的用户思维方式。

Git的4个区5种状态

四个区

1.工作区
2.展缓区
3.本地库
4.远程库

五种工作状态

1.未修改
2.已修改
3.已暂缓
4.已提交
5.已推送

一开始是未修改状态，没有任何修改，开发者进行增删改等一些操作，变成已修改状态，这个时候操作都是在工作区。通过命令行输入git add .，变成已暂缓状态，这个时候已经进入了展缓区。输入git commit，变成已提交状态，这个时候是提交进入了本地库。输入git push，变成了已推送状态，最后是这时已经推送到了远程库了。

GitLab Flow

master主分支

不同的环境建一个分支

服务端环境 — 分支1

测试环境 — 分支2

预发环境 — 分支3

正式环境 — 分支4

一个环境建一个分支，代码合并的顺序要按环境依次推送
注：合并分支最好加上no-ff这个参数，可以看到一个清晰的提交历史，可以看到被合并分支的存在

prodution发布版本分支

当对外发布时，才需要创建的分支
每一个版本从muster分支拉出去一个分支，比如2-1-stable，2-2-stable等，发现bug就从对应的版本分支创建修复分支，完成后合并到master分支
注：遵循“上游优先”原则

Git Work Flow

分支：

1.master分支 — 公用分支 — 对外发布稳定版本

2.dev分支 — 公用分支 — 主要用于合并代码并打包测试

3.feature分支 — 独立分支 — 主要用于开发功能

4.hotfix — 独立分支 — 一般用于修复已发布版本的bug

这些分支又分为

长期分支：

用来放稳定版代码
以发布式发布
方便后续开发
测试稳定性

主题分支：

为了解决某一个问题或者实现某一种功能创建的分支
频繁的创建，使用，合并，删除

Git工作流程

(1)首先所有的东西都在master分支上。我们不可能直接在master分支上进行开发，(2)所以需要重新拉一个分支，dev分支。这个dev分支是所有功能集成的分支，项目一般是合作开发。每个人开发的功能不同，所以分到每个开发者，(3)重新在dev分支下拉一个属于自己的分支，在自己的分支上进行开发。随便你在自己的分支上怎么改，都不会影响到其他人。当所有开发完成了自己的功能，(4)合并到了dev分支上的时候，不能直接把dev分支合并到master分支上。(5)得重新拉一个release分支，将dev分支合并到release分支上。(6)再将release分支合并到master分支上和dev分支上，合并之后记得将release分支删除。(7)通过master分支进行发布。如果发布之后出现了bug，需要修改，不要直接再master分支。(8)重新再master分支上拉一个hotfix分支，在hotfix分支上进行bug修复，(9)修复完后再合并到master分支和dev分支上，合并完之后记得删除hotfix分支,发布之后再出现bug重新回到第7步

流程图：