Git 原理与使用进阶
1. 远程操作
1.1 理解分布式版本控制系统
目前所说的所有内容（工作区、暂存区、版本库等），都是在本地，也就是在你的笔记本或者计算机上。而我们的 Git 其实是分布式版本控制系统！这意味着每个人的电脑上都是一个完整的版本库，这样工作的时候就不需要联网了，因为版本库就在自己的电脑上。
既然每个人电脑上都有一个完整的版本库，那多人如何协作呢？比如你在自己电脑上改了文件 A，你的同事也在他的电脑上改了文件 A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。
分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了。也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当'中央服务器'的电脑，但这个服务器的作用仅仅是用来方便'交换'大家的修改，没有它大家也一样干活，只是交换修改不方便而已。有了这个'中央服务器'的电脑，这样就不怕本地出现什么故障了（比如运气差，硬盘坏了，上面的所有东西全部丢失，包括 git 的所有内容）。
1.2 远程仓库
Git 是分布式版本控制系统，同一个 Git 仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以'克隆'这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。
现实中往往是这样，找一台电脑充当服务器的角色，每天 24 小时开机，其他每个人都从这个'服务器'仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。完全可以自己搭建一台运行 Git 的服务器，不过现阶段，为了学 Git 先搭个服务器绝对是小题大做。好在这个世界上有个叫 GitHub 的网站，提供 Git 仓库托管服务，只要注册一个账号，就可以免费获得 Git 远程仓库。
1.3 新建远程仓库
新建远程项目仓库，填写基本信息，创建成功后，可以对远程仓库进行一个基本的设置：开源或私有。
从创建好的远程仓库中便能看到，之前在本地学习过的分支，也存在于远程仓库中并被管理起来了。刚创建的仓库有且只有一个默认的 master 分支。
1.4 克隆远程仓库—HTTPS/SSH 协议
克隆/下载远端仓库到本地，需要使用 git clone 命令，后面跟上我们的远端仓库的链接，远端仓库的链接可以从仓库中找到：选择'克隆/下载'获取远程仓库链接。
SSH 协议和 HTTPS 协议是 Git 最常使用的两种数据传输协议。SSH 协议使用了公钥加密和公钥登陆机制，体现了实用性和安全性，使用此协议需要将我们的公钥放上服务器，由 Git 服务器进行管理。使用 HTTPS 方式时，没有要求，可以直接克隆下来。
使用 SSH 方式克隆仓库，由于我们没有添加公钥到远端库中，服务器拒绝了我们的 clone 链接。需要我们设置一下：
- 创建 SSH Key。在用户主目录下，看看有没有.ssh 目录，如果有，再看看这个目录下有没有 id_rsa 和 id_rsa.pub 这两个文件，如果已经有了，可直接跳到下一步。如果没有，需要创建 SSH Key。
- 添加自己的公钥到远端仓库。点击 ssh 公钥选项进行设置：点击确认后，需要对您进行认证，输入你的账号密码即可。至此，我们的准备工作全部做完。
当我们从远程仓库克隆后，实际上 Git 会自动把本地的 master 分支和远程的 master 分支对应起来，并且，远程仓库的默认名称是 origin。在本地我们可以使用 git remote 命令，来查看远程库的信息，或者用 git remote -v 显示更详细的信息。
1.5 向远程仓库推送
本地已经 clone 成功远程仓库后，我们便可以向仓库中提交内容，例如新增一个 file.txt 文件。
提交时要注意，如果我们之前设置过全局的 name 和 e-mail，这两项配置需要和 gitee 上配置的用户名和邮箱一致，否则会出错。或者从来没有设置过全局的 name 和 e-mail，那么我们第一次提交时也会报错。这就需要我们重新配置下了，同样要注意需要和 gitee 上配置的用户名和邮箱一致。
到这里我们已经将内容提交至本地仓库中，如何将本地仓库的内容推送至远程仓库呢，需要使用 git push 命令，该命令用于将本地的分支版本上传到远程并合并。命令格式如下：
git push origin master
此时我们要将本地的 master 分支推送到 origin 主机的 master 分支，则可以像上面那样写。推送成功！这里由于我们使用的是 SSH 协议，是不用每一次推送都输入密码的，方便了我们的推送操作。如果你使用的是 HTTPS 协议，有个麻烦的地方就是每次推送都必须输入口令。
1.6 拉取远程仓库
在远程仓库上修改文件并在线更新它（建议还是在本地仓库修改代码，然后推送到远端仓库）。修改内容：增加一个 hello world。
此时，远程仓库是要领先于本地仓库一个版本，为了使本地仓库保持最新的版本，我们需要拉取下远端代码，并合并到本地。Git 提供了 git pull 命令，该命令用于从远程获取代码并合并本地的版本。
git pull
我们发现，拉取成功了！
1.7 忽略特殊文件
在日常开发中，我们有些文件不想或者不应该提交到远端，比如保存了数据库密码的配置文件，那怎么让 Git 知道呢？在 Git 工作区的根目录下创建一个特殊 .gitignore 文件，然后把要忽略的文件名填进去，Git 就会自动忽略这些文件了。
不需要从头写 .gitignore 文件，可以在工作区创建一个也是可以的。无论哪种方式，最终都可以得到一个完整的 .gitignore 文件，例如我们想忽略以.so 和.ini 结尾所有文件，.gitignore 的内容如下：
*.so
*.ini
接着我们就来验证一下 .gitignore 文件的能力，在工作区新增两个文件 a.so b.ini：检验 .gitignore 的标准就是 git status 命令是不是说 working tree clean。我们发现 Git 并没有提示在工作区中有文件新增，果然 .gitignore 生效了！但有些时候，你就是想添加一个文件到 Git，但由于这个文件被 .gitignore 忽略了，根本添加不了，那么可以用 -f 强制添加；或者你发现可能是 .gitignore 写得有问题，需要找出来到底哪个规则写错了，比如说 d.so 文件是要被添加的，可以用 git check-ignore 命令检查：
Git 会告诉我们，.gitignore 的第 3 行规则忽略了该文件，于是我们就可以知道应该修订哪个规则。还有些时候，当我们编写了规则排除了部分文件时，但是我们发现 .* 这个规则把 .gitignore 也排除了。虽然可以用 git add -f 强制添加进去。但有强迫症的童鞋还是希望不要破坏 .gitignore 规则。这个时候，可以添加一条例外规则；把指定文件排除在 .gitignore 规则外的写法就是 ! + 文件名，所以，只需把例外文件添加进去即可。
最后一步就是把 .gitignore 和相关创建的文件也提交到远端就完成了！
1.8 给命令配置别名
在我们使用 Git 期间，有些命令敲的时候着实让人头疼（太长了…）幸运的是 Git 支持对命令行简化！举个例子，将 git status 简化为 git st，对应的命令为：
git config --global alias.st status
–global 参数是全局参数，也就是这些命令在这台电脑的所有 Git 仓库下都有用。如果不加，那只针对当前的仓库起作用。好了，现在敲 git st 看看效果。
不过，我个人还是不推荐大家现在去使用命令简化等大家工作了，再去简化自己的工作吧，目前所有的命令都要手动完成，让大家尽快适应 Git！
2. 标签管理
2.1 理解标签
标签 tag，可以简单的理解为是对某次 commit 的一个标识，相当于起了一个别名。例如，在项目发布某个版本的时候，针对最后一次 commit 起一个 v1.0 这样的标签来标识里程碑的意义。这有什么用呢？相较于难以记住的 commit id，tag 很好的解决这个问题，因为 tag 一定要给一个让人容易记住，且有意义的名字。当我们需要回退到某个重要版本时，直接使用标签就能很快定位到。
2.2 创建标签
在 Git 中打标签非常简单。首先切换到需要打标签的分支上，然后，敲命令 git tag [name] 就可以打一个新标签：可以用命令 git tag 查看所有标签：默认标签是打在最新提交的 commit 上的。
那如何在指定的 commit 上打标签呢？方法是找到历史提交的 commit id，然后打上就可以了，示例如下：
git tag v1.0 <commit_id>
注意，标签不是按时间顺序列出，而是按字母排序的。可以用 git show [tagname] 查看标签信息。
Git 还提供可以创建带有说明的标签，用 -a 指定标签名，-m 指定说明文字，格式为：
git tag -a v1.0 -m "version 1.0 release"
另外，打完标签之后，使用 tree .git 命令查看一下你的本地库有什么变化，肯定能帮助你理解！
2.3 操作标签
如果标签打错了，也可以删除。
因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
如果要推送某个标签到远程，使用命令 git push origin <tagname>。
此时，查看远端码云，看到了标签已经被更新！
当然，如果你本地有很多标签，也可以一次性的全部推送到远端。
如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：然后，从远程删除。删除命令也是 push，但是格式如下：
git push origin --delete <tagname>
在码云上查看确实删除成功！
3. Git 实战场景—多人协作一
3.1 完成准备工作
目前，我们所完成的工作如下：
- 基本完成 Git 的所有本地库的相关操作，git 基本操作，分支理解，版本回退，冲突解决等等。
- 申请码云账号，将远端信息 clone 到本地，以及推送和拉取。是时候干最重要的事情了，实现多人协作开发！为了做这件事情，我们需要先做一些准备工作。我们之前已经将项目 clone 到了指定目录。
我们在 mac 环境下（如果你的是 windows 环境就在 windows 下进行操作），再 clone 同一个项目仓库，来模拟和你一起协作开发的另一名小伙伴：
git clone <repository_url>
这样我就把我 gitee 里面的项目文件 Clone 成功到我的 mac 电脑的 git 文件夹中了！
3.2 协助开发
目前，我们的仓库中只有一个 master 主分支，但在实际的项目开发中，在任何情况下其实都是不允许直接在 master 分支上修改代码的，这是为了保证主分支的稳定。所以在开发新功能时，常常会新建其他分支，供开发时进行迭代使用。那么接下来，就让我们在 gitee 上新建 dev 远程分支供我们使用，并将它拿到本地仓库。
在 dev 分支下向 file.txt 里面增加"aaa"的内容，并把它 push 到远端仓库的 dev 分支下，至此开发者 1 的任务已经完成了！
开发者 2 将自己电脑本地的仓库代码分支与远端分支匹配一致。
我们向 file.txt 文件里面增加"bbb"的内容，并把它推送到远端仓库。
但是我们会发现有合并冲突，因为开发者 1 添加的"aaa"内容和开发者 2 添加的"bbb"内容不一致，而我们最终想要的是"aaa、bbb"的文件内容，所以我们需要进行修改！
解决完冲突后，我们再次进行代码提交，我们就会发现成功了！
此时，我们看到远端的码云已经能看到我们的新提交了！由此，两名开发者已经开始可以进行协同开发了，不断的 git pull/add/commit/push，遇到了冲突就使用我们之前讲的冲突处理解决掉冲突。对于开发者 1 来说，要想看到开发者 2 的代码只需要 pull 一下即可。最后不要忘记，虽然我们是在分支上进行多人协作开发，但最终的目的是要将开发后的代码合并到 master 上去，让我们的项目运行最新的代码。
3.3 将内容合并进 master
我们查看 master 分支时会发现里面的代码并不是我们设想的那样，重要原因是缺少了 merge 操作！
方法一：我们可以使用 Pull Requests 进行 merge 操作，来合并分支。
方法二：在本地仓库中进行 master 和 dev 到 merge 操作。
- 切换至 master 分支，pull 一下，保证本地的 master 是最新内容。合并前这么做是一个好习惯。
- 切换至 dev 分支，合并 master 分支。这么做是因为如果有冲突，可以在 dev 分支上进行处理，而不是在 master 上解决冲突。这么做是一个好习惯。
- 切换至 master 分支，合并 dev 分支，将 master 分支推送至远端。
此时，查看远端仓库，master 已经是最新代码了：
此时，dev 分支对于我们来说就没用了，那么 dev 分支就可以被删除掉。我们可以直接在远程仓库中将 dev 分支删除掉：
git push origin --delete dev
总结在同一分支下进行多人协作的工作模式通常是这样：
- 首先，可以尝试用
git push origin branch-name推送自己的修改； - 如果推送失败，则因为远程分支比你的本地更新，需要先
git pull试图合并； - 如果合并有冲突，则解决冲突，并在本地提交；
- 没有冲突或者解决掉冲突后，再用
git push origin branch-name推送就能成功！ - 功能开发完毕，将分支 merge 进 master，最后删除分支。
4. Git 实战场景—多人协作二
4.1 协助开发 1
一般情况下，如果有多需求需要多人同时进行开发，是不会在一个分支上进行多人开发，而是一个需求或一个功能点就要创建一个 feature 分支。现在同时有两个需求需要开发者 1 和开发者 2 进行开发，那么你们俩便可以各自创建一个分支来完成自己的工作。
任务目标：
- 对于开发者 1 来说可以进行以下操作：新增本地分支 feature-1 并切换，新增需求内容 - 创建 function1 文件，将 feature-1 分支推送到远端。
- 对于开发者 2 来说，可以进行以下操作：创建并切换到 feature-2 分支，在分支下为需求新增 function2 文档，将 feature-2 分支推送至远端。
此时，在本地，开发者 1 看不见开发者 2 新建的文档，开发者 2 看不见开发者 1 新建的文档。并且推送各自的分支时，并没有任何冲突，开发者俩互不影响，用起来很舒服！！！再来看下远端码云上此时的状态：
对于开发者 feature-1 分支，对于开发者 2 feature-2 分支，正常情况下，开发者就可以在自己的分支上进行专业的开发了！但天有不测风云，开发者 2 突然生病了，但需求还没开发完，需要开发者 1 帮他继续开发，于是他便把 feature-2 分支名告诉你了。这时开发者 1 就需要在自己的机器上切换到 feature-2 分支帮忙继续开发，要做下面的操作。
4.2 协助开发 2
必须先拉取远端仓库内容，可以看到远程已经有了 feature-2，切换到 feature-2 分支上，可以和远程的 feature-2 分支关联起来，否则将来只使用 git push 推送内容会失败。开发者 1 向 function2.txt 文件里面增加"i am coding"的内容！
切换成功后，便可见 feature-2 分支中的 function2.txt 文件了，接着就可以帮开发者 2 进行开发：查看远程状态，推送成功了！这时，开发者 2 已经修养的差不多，可以继续进行自己的开发工作，那么他首先要获取到开发者 1 帮他开发的内容，然后接着开发者 1 的代码继续开发。或者开发者 1 已经帮开发者 2 开发完了，那开发者 2 也需要在自己电脑上看看开发者 1 帮他写的代码：
Pull 无效的原因是开发者 2 没有指定本地 feature-2 分支与远程 origin/feature-2 分支的链接，根据提示，设置 feature-2 和 origin/feature-2 的链接即可：目前，开发者 2 的本地代码和远端保持严格一致。开发者 1 和开发者 2 可以继续在不同的分支下进行协同开发了。各自功能开发完毕后，不要忘记我们需要将代码合并到 master 中才算真正意义上的开发完毕！
4.3 将内容合并进 master
由于开发者 2 率先开发完毕，于是开始 merge，切换 master，pull 一下，保证本地 master 是最新的内容。切换至 feature-2 分支，合并 master 分支，切换至 master 分支，合并 feature-2 分支。将 master 分支推送至远端，此时远程仓库的状态：
当开发者 2 将其代码 merge 到 master 后，这时开发者 1 也开发完成了，也需要进行 merge 到 master 操作：
- 切换至 master 分支，pull 一下，保证本地的 master 是最新内容。合并前这么做是一个好习惯。
- 切换至 feature-1 分支，合并 master 分支。这么做是因为如果有冲突，可以在 feature-1 分支上进行处理，而不是在 master 上解决冲突。这么做是一个好习惯。
- 由于 feature-1 分支已经 merge 进来了新内容，为了保证远程分支最新，所以最好 push 一下。要 push 的另一个原因是在实际的开发中，master 的 merge 操作一般不是由我们自己在本地进行操作，其他人员或某些平台 merge 时，操作的肯定是远程分支，所以就要保证远程分支的最新。如果 merge 出现冲突，不要忘记需要 commit 才可以 push！！
- 切换至 master 分支，合并 feature-1 分支，将 master 分支推送至远端：
此时，feature-1 和 feature-2 分支对于我们来说就没用了，那么我们可以直接在远程仓库中将 dev 分支删除掉。这就是多人协作的工作模式，一旦熟悉了，就非常简单！
5. 解决 branch -a 打印已被删除的远程分支的办法
当前我们已经删除了远程的几个分支，使用 git branch -a 命令可以查看所有本地分支和远程分支，但发现很多在远程仓库已经删除的分支在本地依然可以看到。例如下面，使用命令 git remote show origin，可以查看 remote 地址，远程分支，还有本地分支与之相对应关系等信息。此时我们可以看到那些远程仓库已经不存在的分支，根据提示，使用 git remote prune origin 命令：这样就删除了那些远程仓库不存在的分支。对于本地仓库的删除。之前已经介绍过了，大家可以自行从操作。
6. 企业级开发模型
6.1 企业级开发流程
我们知道，一个软件从零开始到最终交付，大概包括以下几个阶段：规划、编码、构建、测试、发布、部署和维护。最初，程序比较简单，工作量不大，程序员一个人可以完成所有阶段的工作。但随着软件产业的日益发展壮大，软件的规模也在逐渐变得庞大。软件的复杂度不断攀升，一个人已经 hold 不住了，就开始出现了精细化分工。
但在传统的 IT 组织下，开发团队 (Dev) 和运维团队 (Ops) 之间诉求不同：
- 开发团队 (尤其是敏捷团队) 追求变化
- 运维团队追求稳定
双方往往存在利益的冲突。比如，精益和敏捷的团队把持续交付作为目标，而运维团队则为了线上的稳定而强调变更控制。部门墙由此建立起来，这当然不利于 IT 价值的最大化。为了弥合开发和运维之间的鸿沟，需要在文化、工具和实践方面的系列变革——DevOps 正式登上舞台。
DevOps(Development 和 Operations 的组合词) 是一种重视'软件开发人员 (Dev)'和'IT 运维技术人员 (Ops)'之间沟通合作的文化、运动或惯例。透过自动化'软件交付'和'架构变更'的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在 DevOps 的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控，由此可见 DevOps 的强大。
讲了这么多，这个到底和我们的主题 Git 有什么关系呢？举一个很简单的例子就能说明这个问题。一个软件的迭代，在我们开发人员看来，说白了就是对代码进行迭代，那么就需要对代码进行管理。如何管理我们的代码呢，那不就是 Git(分布式版本控制系统)！所以对于开发人员来说其重要性就不言而喻了。
6.2 系统开发环境
对于开发人员来说，在系统开发过程中最常用的几个环境必须要了解一下：
- 开发环境：开发环境是程序员们专门用于日常开发的服务器。为了开发调试方便，一般打开全部错误报告和测试工具，是最基础的环境。
- 测试环境：一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。该环境是开发环境到生产环境的过渡环境。
- 预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测而设立的一套环境。其配置等基本和生产环境一致，目的是能让我们发正式环境时更有把握！所以预发布环境是你的产品质量最后一道防线，因为下一步你的项目就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内，为单独的一些机器。
- 生产环境：是指正式提供对外服务的线上环境，例如我们目前在移动端或 PC 端能访问到的 APP 都是生产环境。
这几个环境也可以说是系统开发的三个重要阶段：开发->测试->上线。一张图总结：
对于规模稍微大点的公司来说，可不止这么几个环境，比如项目正式上线前还存在仿真/灰度环境，再比如还存在多套测试环境，以满足不同版本上线前测试的需要。一个项目的开始从设计开始，而一个项目的成功则从测试开始。一套良好的测试体系可以将系统中绝大部分的致命 Bug 解决在系统上线之前。测试系统的完善和成熟也是衡量一个软件企业整体水平的重要指标之一，测试往往被忽视，因为它对可以的隐性、对软件开发企业不产生直接的效益，但是它却是软件质量的最终保障，乃至项目能否成功的重要因素！
6.3 Git 分支设计规范
环境有了概念后，那么对于开发人员来说，一般会针对不同的环境来设计分支，例如：
注：以上表格中的分支和环境的搭配仅是常用的一种，可视情况而定不同的策略。
- master 分支
- master 为主分支，该分支为只读且唯一分支。用于部署到正式发布环境，一般由合并 release 分支得到。
- 主分支作为稳定的唯一代码库，任何情况下不允许直接在 master 分支上修改代码。
- 产品的功能全部实现后，最终在 master 分支对外发布，另外所有在 master 分支的推送应该打标签 (tag) 做记录，方便追溯。
- master 分支不可删除。
- release 分支
- release 为预发布分支，基于本次上线所有的 feature 分支合并到 develop 分支之后，基于 develop 分支创建。可以部署到测试或预发布集群。
- 命名以 release/开头，建议的命名规则：release/version_publishtime。
- release 分支主要用于提交给测试人员进行功能测试。发布提测阶段，会以 release 分支代码为基准进行提测。
- 如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。
- release 分支属于临时分支，产品上线后可选删除。
- develop 分支
- develop 为开发分支，基于 master 分支创建的只读且唯一分支，始终保持最新完成以及 bug 修复后的代码。可部署到开发环境对应集群。
- 可根据需求大小程度确定是由 feature 分支合并，还是直接在上面开发 (非常不建议)。
- feature 分支
- feature 分支通常为新功能或新特性开发分支，以 develop 分支为基础创建 feature 分支。
- 命名支。以 feature/开头，建议的命名规则：feature/user_createtime_feature。
- 新特性或新功能开发完成后，开发人员需合到 develop 分支。
- 一旦该需求发布上线，便将其删除。
- hotfix 分支
- hotfix 分支为线上 bug 修复分支或叫补丁分支，主要用于对线上的版本进行 bug 修复。当线上出现紧急问题需要马上修复时，需要基于 master 分支创建 hotfix 分支。
- 命名以 hotfix/开头，建议的命名规则：hotfix/user_createtime_hotfix。
- 当问题修复完成后，需要合并到 master 分支和 develop 分支并推送远程。一旦修复上线，便将其删除。
其实，以上跟大家讲解的是企业级常用的一种 Git 分支设计规范：Git Flow 模型。但要说的是，该模型并不是适用于所有的团队、所有的环境和所有的文化。如果你采用了持续交付，你会想要一些能够尽可能简化交付过程的东西。有些人喜欢基于主干的开发模式，喜欢使用特性标志。然而，从测试的角度来看，这些反而会把吓一跳。关键在于站在你的团队或项目的角度思考：这种分支模型可以帮助你们解决哪些问题？它会带来哪些问题？这种模式为哪种开发提供更好的支持？你们想要鼓励这种行为吗？你选择的分支模型最终都是为了让人们更容易地进行软件协作开发。因此，分支模型需要考虑到使用者的需求，而不是盲目听信某些所谓的'成功的分支模型'。所以对于不同公司，规范是会有些许差异，但万变不离其宗，是为了效率与稳定。
6.4 企业级项目管理实战—准备工作
创建项目，创建仓库，添加成员：
- 添加企业成员
- 添加项目成员
- 添加仓库开发人员
6.5 开发场景—基于 git flow 模型的实践
现有有一个订单管理的新需求需要开发，首先可以基于 develop 分支创建一个 feature/yb_20231010_pay 分支。
- 需求在 feature/yb_20231010_pay 分支开发完毕，这时研发人员可以将代码合并到 develop 分支，将其部署在开发环境的服务器中，方便开发人员进行测试和调试。
- a. 开发者在 feature 分支下发起请求评审比。
- b. 审查员审查代码。
- c. 审查通过，合并分支。
- d. 合并成功，查看结果。
- 在 develop 下开发人员自测通过后，先确定下 develop 不存在未测试完毕的需求，然后研发人员可基于 develop 分支创建一个 release/xxx 分支出来，可交由测试人员进行测试。
- 测试人员测试 release 通过后 (包含测试环境和预发布环境的测试)，就可将代码合并入 master。
- 测试人员在 master(正式环境) 测试通过后，便可删除 feature/xxx 分支。
❶ 修复测试环境 Bug 在 develop 测试出现了 Bug，建议大家直接在 feature 分支上进行修复。修复后的提测上线流程与新需求加入的流程一致。
❷ 修改预发布环境 Bug 在 release 测试出现了 Bug，首先要回归下 develop 分支是否同样存在这个问题。如果存在，修复流程与修复测试环境 Bug 流程一致。如果不存在，这种可能性比较少，大部分是数据兼容问题，环境配置问题等。
❸ 修改正式环境 Bug 在 master 测试出现了 Bug，首先要回归下 release 和 develop 分支是否同样存在这个问题。如果存在，修复流程与修复测试环境 Bug 流程一致。如果不存在，这种可能性也比较少，大部分是数据兼容问题，环境配置问题等。
❹ 紧急修复正式环境 Bug 需求在测试环节未测试出 Bug，上线运行一段时候后出现了 Bug，需要紧急修复的。有的企业面对紧急修复时，支持不进行测试环境的验证，但还是建议验证下预发布环境。可基于 master 创建 hotfix/xxx 分支，修复完毕后发布到 master 验证，验证完毕后，将 master 代码合并到 develop 分支，同时删掉 hotfix/xxx 分支。
