【字节青训营-2】：深入Git研发流程与Github Flow简单实战

本文为笔者参加字节青训营时听字节青训课所做的笔记。

一、工作流介绍

集中式工作流：比如传统的SVN、Gerrit（Google），只依托主干分支进行开发，不存在其他的分支，合入的方式是Fast-forward。

分支管理工作流：Github、Gitlab，可以定义不同特性的开发分支，上线分支，在开发分支完成之后再通过MR\PR合入主干分支，合入方式比较灵活，可以自定义、可以Fast-Forward或者Three-Way Merge都可以的。

二、集中式工作流

本质上就是：只依托master分支进行研发活动。

首先在远端master获取代码，然后直接在master分支上进行修改，提交前拉取最新的master代码和本地的代码进行合并（使用rebase），如果有冲突则需要解决对应的冲突。

最典型的就是Gerrit，谷歌开发的代码托管平台，主要特点是能够进行很好的代码评审。在AOSP（安卓开源代码）中使用广泛。

Gerrit原理如下：
1、依托Change ID的概念，每个提交生成一个单独的代码评审。
2、提交上去的代码不会存储在真正的refs/heads下的分支，而是在一个refs/for的引用下。
3、通过refs/meta/config下的文件存储代码的配置，包括权限、评审等配置，每个change都必须要完成对应的Review后才能合入。

所以针对上面的机制，Gerrit的优点就很明显了，比如：
1、提供强制的代码评审机制，保证了代码质量。
2、提供更加丰富的权限功能，可以对分支做细粒度的权限管控。
3、保证了master的历史整洁性。
4、Aosp多仓的场景支持更好。

缺点也比较明显，比如容易冲突，多分支的支持比较差，难以形成在项目之间的代码复用（主要是fork这种操作就不太支持）。

三、分支管理工作流

主要有三种：
1、Git Flow：分支类型丰富，规范严格。
2、Github Flow：只有主干分支和开发分支，规则简单。
3、Gitlab Flow：在主干分支和开发分支上构建环境分支、版本分支，满足不同发布or环境的需要。

3.1 GitFlow

包含五种分支：Master主干分支、Develop研发分支、Featrue特性分支、Release发布分支、Hotfix热修复分支。

相对来说，如果能够按照定义的标准严格执行，代码会很清晰，但是可以预测的事流程过于复杂了，并且上线节奏很慢，研发容易不按标准进行执行。

3.2 Github Flow

Github工作流只有一个主干分支，基于Pull Request往主干分支中提交对应的代码。

团队的合作方式：
1、owner创建好仓库之后，其他用户通过Fork的方式来创建自己的仓库，并且在fork的仓库上进行开发。（开源库的合作方式。）
2、owner创建之后，给成员分配权限，直接在一个仓库内进行开发。

四、Github Flow简单实战

接下来我们开始在Github上面创建一个仓库进行简单的实战，首先在github上创建一个名称为demo的仓库。

我们创建好之后在vscode上复制对应的ssh连接进行clone：

git clone git@github.com:<你的github用户名>/demo.git

这里会提示我们似乎克隆了一个空仓库。

然后我们创建一个read.me文件。

依次完成下面的代码：
git add .\和git commit -m "add readme" 和git push origin main三条命令。

然后在github上就可以看到对应的仓库文件了，到此我们创建了一个main主分支。

接着我们创建一个feature分支。

依次执行下面的命令

git checout -b feature
git add .
git commit -m "update readme"
git push origin feature

回到对应的github可以看到提示如上图。

在Github中也可以看到对应的一个pull request，点击Create pull request，就可以看到对应的分支记录。

能够在github选择对应的分支。

也可以查到对应的代码变更：

代码变更旁边的checks是加对应的代码质量检查。

如果check之后没有问题就可以点击Merge Pull Merge合并了。

这个时候再去main分支查看的话，就可以看到已经合并之后的代码了。

在vscode本地中，我们先切换回main分支，然后把origin main分支的pull下来，然后git log查看就可以发现对应的merge记录了。

在github上我们也可以为分支设置一些保护机制：

这里有一些常见的保护分支的配置：比如一定要通过同意merge才能进行push、一定要经过讨论pass才能push等。

五、代码合并

Fast-Forward：不会产生一个merge节点，合并之后保持一个线性历史，如果target分支有更新，则需要通过rebase操作更新source branch之后才可以合入。

第二种方式是Tree-Way Merge，也就是三方合并，会产生一个新的merge节点。

注意保护分支是必须通过PR进行合入。
Code Review，CI：都是在合入前的检查策略， Code Review是人工进行检查，CI则是通过一些定制化脚本进行校验。

同时需要注意Fast-Forward 和Three way Merge的区别，本地代码更新频繁的使用Tree Way的方式，导致生成过多的Merge节点，使得历史变得复杂不清晰。