Git超详解八 git工作流

1.Git工作流

- 因为Git功能实在太强大了，太灵活了。这导致如果每个人都有自己的习惯，而不统一遵循一个规范，
那么一起协作开发将变成灾难性的。
- 所以有Git工作流来规范大家的行为，工作流大部分情况都是规范分支的使用。
- 不同的Git平台，都有可能自己不同的Git工作流，以下进行讲解。

2.Git基本工作流

Git基本工作流是规定长期存在两个分支master和dev。

2.1master分支

master分支：合并到master分支上的代码都是经过测试，没有问题，可以发布到线上环境的代码。
dev分支：用于合并公司所有同事最新的开发代码的分支，上面可能会存在bug。

然后这两个长期分支下，还存在以下分支：

2.2.1Feature分支

Feature分支：特征分支，比如我现在和前端一起开发一个登录的功能，那我就可以创建一个登录的分支和前端开发一起协作。

2.2.2Release分支

Release分支：版本分支。比如我们现在开发了v2.0版本的代码，那么在合并到master分支之前，先合并到release-v20分支，然后经过深度测试，没有问题后再把代码合并到master分支和dev分支，一旦确定没有问题，就可以将这个分支删掉了。

2.2.3bug分支

bug分支：比如现在master分支上的代码在运行过程中出现了紧急的bug，那么我们可以从master分支上开一个bug分支，把问题解决后再合并到master分支，并且这个bug分支也可以被删掉了。

3.Github工作流

Github的工作流最大的特点是，只有一个master主分支，团队成员如果想要合并代码，通过发送Pull Request，然后管理员审核通过后再合并到master分支。如果你不是项目管理员，那么你可以先在自己的分支上进行变基，然后再发送一个PR，别人看到你这个PR，如果没有问题，他合并的时候就直接用Fast-Forward了，不需要去解决冲突等问题了。

4.Gitlab工作流

GitLab结合了Git基本工作流和GitHub工作流。既支持多个长期分支，也支持将分支设置为受保护的，其他人想要合并代码，需要发一个Merge Request，管理员审核通过后才能进行合并。