gitflow 开发流程学习（第二部分）-原创手记-慕课网

续前文：gitflow 开发流程学习（第一部分） | 线上猛如虎，线下怂如鼠（WhyNotBetter）

如何做好版本的发布？（tag）

先补充一部分前文的内容，前文说明了一般的 git 开发流程会遇到的情况，虽然却少了一个地方，前文的图中是有一个地方没有说到，就是 tag：

同大多数 VCS 一样，Git 也可以对某一时间点上的版本打上标签。人们在发布某个软件版本（比如 v1.0 等等）的时候，经常这么做，所以当我们对某一个进度结束的时候，都应该打一个标签，既可以记录下当前的版本信息，也可以管理好不同版本的代码区分。

标签不一定是打在 master 分支上，也可以在其他分支，但是 master 分支的 tag 有特殊意义，代表的是这个项目的代码的发布版本，因为发布代码会使用 master 分支进行发布。

例如回到前文的真实应用案例（tag 都是在 master 分支上）：

第一个标签是在项目开始的时候初始化之后，作为版本 v0.1，可以加速备注，说明这是项目初始化。
第二个标签是在开发者 leader c 将 feature/articles 和 feature/login 分支合并到 develop 分支之后，然后检查了代码觉得没问题，可以发布了，就将当前的 develop 分支合并到 master 分支，然后打上 v0.2

// 开发者 leader c
git checkout master  // 切换到 master 分支后才可以打标签
git tag -a v0.1 -m '项目初始化'
git tag -a v0.2 -m '已经完成了文章和登录开发'

然后基于不同的 tag 标签来拉取代码进行发布即可完成真正的项目开发到发布的流程。

最重要的是，一旦打了当前版本的标签，就不能再继续放代码进去，保证这个版本的标签对应得到你的版本，不然就没有了版本的意义了。

引入测试团队做测试的话，你要怎么做？（release 分支）

项目引入了测试人员，他们要对代码进行测试，测试结果合格才能进行代码发布，这也是很正常的一个项目开发需要接触到的流程，那么我们就要新分出一条 release 分支来处理。

release 分支也可以叫发布分支或者叫发布前分支，因为一旦创建出 release 分支就代表即将要进行代码发布，
Release 分支基于 Develop 分支创建，打完 Release 分之后，我们可以在这个 Release 分支上测试，修改 Bug，补充文档等。同时，其它开发人员可以基于开发新的 Feature。

回到之前的项目开发例子，在引入 release 分支之后是这样，在开发完文章和登录功能后，代码都合并到 develop 分支之后，会从当前的 develop 分支新建一条 release 分支：

// 一般开发者或者开发者 leader 或者测试人员都可以新建一条release 分支
git checkout -b release-0.2 develop // 新建并切换到本地的release-0.2分支

git push origin release-0.2 // 推送到远端代码仓库，测试人员或者其他开发人员就可以在远端代码仓库里面查看和使用这个分支

也可以直接在 gitlab 管理后台创建 release 分支。

推送本地 release 分支到远端代码仓库之后，本项目基于此分支节点的代码就会进入测试阶段，其他人需要以此作为基准，拉取代码进行测试，写文档，修复 bug 等

// 测试后发现 bug，例如发现了 login 功能有一个 bug，无法登录 admin 账户
// 开发者操作如下：
git fetch // 更新所有远端分支信息
git checkout -b release-0.2 orgin/release-0.2 // 基于远端分支创建新的本地分支，并且切换过去
git pull origin release-0.2 // 拉取远端release-0.2到本地（为了保险起见，保证代码是最新的，也可以忽略不做这个操作）

// 测试人员会使用这条分支的代码进行测试，发现问题会提交 issue 或者提交其他 bug 管理系统

// 开发人员看到测试人员提交的 bug，会使用这条分支的代码进行bug 修复
// 修复完成后推送到远端的release-0.2分支，已被测试人员再次测试
git push origin release-0.2 // 推送到远端代码仓库

推送到远端代码仓库后，测试人员会重新进行检查，确认所有测试都通过后，然后相关人员（qa 或者开发者 leader）和将其 release-0.2 分支合并到 develop 分支和 master 分支，保证该版本在开发分支和主发布分支（master）上是一致的。

在 gitlab 上，远端分支合并都必须在 gitlab 的管理后台进行。

合并结束后，开发者 leader 会对当前的 master 分支打一个 tag，例如 v0.2，就可以代表可以发布的版本了，部署人员就可以使用这个 tag 的代码进行发布了。

如果线上环境出现问题怎么修复？（hotfix 分支）

如果项目线上除了问题，需要进行紧急修复，那么就会跳过一切不必要的分支和流程，直接从 master 当前基点拉取一条新分支 hotfix 分支来进行修复，修复结束后需要合并到 master 和 develop 分支，以保证代码的最新版本。

// 被发现线上系统有严重 bug 之后，开发者本地操作
git fetch // 任何时候都最好 fetch 一下远端代码仓库的最新信息

// 基于远端 master 分支创建一个本地 hotfix 分支，并切换过去
git checkout -b hotfix-0.3 orgin/master  // 这里数字是以当前 master 版本0.2的基础上增加，证明这是一个新的版本，并且会更新 tag 为0.3
// 漏洞修复...
// 修复完后
git push origin hotfix-0.3 // 推送到远端代码仓库

然后经过测试人员检查没问题，由开发者 leader 在 gitlab 后台将 hotfix-0.3 分支和 master 分支进行分支合并，并且对 master 打上一个 v0.3 的标签，然后部署人员就可以使用这个标签的代码进行部署发布。

补充备注项

在 gitlab 上，远程分支的合并是必须要在 gitlab 后台进行的，这个跟一般的 git 操作远程分支是有区别的，也是为了保证代码不被随意合并。
这里没说短期（临时）分支需要被删除的情况，前文说过，feature 、hotfix、release、bugfix在其功能完成后需要删除，不过这个看你怎么想，如果你的功能分支比较大，那么可以不必删除，作为保留方便查看，如果你的功能分支比较细，那么最好还是要删除，因为太多了，但是需要在合并的分支的时候注明好，以方便查看和使用。
gitflow 流程你可以完全遵守，也可以只遵守一部分，在乎你们公司怎么管理代码，怎么安排人员和怎么配合项目开发，没有死板的规范，只有不适合的规范。
这里没怎么说 rebase，这里引用知乎上一位高手的说明来解释一下，git merge 和 git rebase 的区别

（1）使用 git merge 合并分支，解决完冲突，执行 add 和 commit 操作，此时会产生一个额外的 commit。如下图：

（2）使用 git rebase 合并分支，解决完冲突，执行 add 和 git rebase —continue，不会产生额外的 commit。这样 master 分支上不会有无意义的 commit。如下图：

所以可以这么说：merge 是显性合并，rebase 是隐性合并。

同理，当你执行 git pull 时，是同时执行了 git fetch 和 git merge 两个操作。如果你不想进行 merge 操作，即不想留下合并的记录，可以使用 git pull --rebase操作。

本文参考到的资料地址：