来来来,要上线了,把不需要上线的功能都注释掉。
这个操作让人有点不可思议。
原本我以为,程序员应该都会用 Git!可是,我发现我错了。
Git
Git 是用来做版本管理的,在使用之前,你可能需要先安装它。但通常情况下是不需要的,因为它真的太重要了,所以大部分的操作系统默认都已经安装过了。
Repository
对于 Git 仓库,有以下两种类型:
- 本地仓库,可以理解为保存在某台主机上不共享的 Git 仓库
本地仓库有太多的限制,比如说:无法远程访问、多人协作等。所以,通常情况下我们都是直接创建远程仓库的。
- 远程仓库,保存在远程服务器上的 Git 仓库
对于远程仓库,我们可以自己搭建 Git 服务器,也可以使用诸如:GitHub(收费)、GitLab、BitBucket 等现成的服务。个人比较推荐使用 GitLab。
一点思考
我想,一些程序员不使用版本管理工具(Git)来管理代码肯定是有原因的,比如说:
- 一个人开发必有必要;
- 感觉没什么用,用不用都没什么影响。
有句话好像是这样说的:“失败的原因各种各样,但成功的原因却大致相同”。我们可以思考一下下面的问题:
- 若你的代码只是保存在电脑上,要是需要在家修改代码怎么办?你不见得去哪都带着电脑吧!万一你用的电脑是台式机,那就尴尬了。
仔细想想,你可能就会觉得确实是那么回事,所以你就在 GitLab 上创建了一个私有的仓库。这是 Git 解决的第一个问题:远程协作
- 在两周的迭代后,我们发布了新的版本,却发现新的版本存在 Bug,老板要求回到上一个稳定版本。
这时候你可能就懵了,因为你已经完全不记得上一个版本是什么样子了。这是 Git 解决的第二个问题:版本控制
- 你可能会还会遇到这样的情况,团队的开发人员在 master 分支上开发的好好的,却接到客服或运营的 Bug 反馈,这时候你要改 Bug 并发布,但是新开发的功能还没开发完。
这时候,你会发现这个问题解决起来却有点麻烦,你可能就需要对大家说:“来来来,要上线了,把不需要上线的功能都注释掉”。这是 Git 要解决的第三个问题:分支管理
这里只介绍 Git 解决的三个主要问题,当然 Git 的功能远不止这些,但这三点是必须要搞明白的。
Workflow
分支管理是 Git 的强大功能,在实际的开发中能解决很多问题。而每个人对分支管理的理解是不同,也就会产生很多种分支管理方法。比如说:有的程序员只使用一个 Master 分支,开发、测试、发布、维护(Bug 修复)都在 Master 分支上完成。这样做必定会产生很多问题。
分支管理的主要目的是:满足整个研发过程中(开发、测试、发布、维护),代码的版本控制。这就需要我们在做分支管理的时候,去决策需要使用多少分支,每个分支分别需要做什么事情,以及什么时候创建/合并分支。而这些就是 Git 的工作流,是我们在整个研发过程中使用 Git 来管理代码的流程和规范。
对于 Git 工作流,常用的主要有三种,如:
- Git Flow
- GitLab Flow
- GitHub Flow
Git Flow 就是我们接下来要说明的。
Branch
首先这种工作流会用到以下几种分支:
- master,主分支,创建 Repository 时默认会生成一个 master 分支。通常情况下 master 分支是受保护的(Protected)。master 分支保存的是稳定的已发布到线上的代码,会使用 tag 来记录发布的版本。master 分支是不允许提交代码的,只能将代码合并(merge)到 master。
- develop,开发分支,从 master 创建。需要注意的是,通常情况下,我们只在 develop 上开发一些基础的代码。而对于一些新的功能,我们是不会在 develop 上开发的,因为你不能确定这些是否需要上线(或者说无法确定在哪次迭代上线)。
- feature,功能分支,从 develop 创建。feature 分支是用来开发新功能的,通常情况下新功能开发完毕后会合并的 develop。
- release,发布分支 从 develop 创建。当一次迭代的功能开发并自测完成后,就可以创建发布分支。该分支通常用于测试,我们不能在该分支上完成除 Bug 修复外的其他工作。测试完成后,我们需要将 release 分支合并到 master 进行发布。发布完成后在 master 打上 tag 记录此次发布的版本,并将 hotfix 合并到 develop。
- hotfix,修复分支,从 master 创建。当我们发现线上 Bug 时,会从 master 分支上对应的 tag 处创建新的 hotfix 分支,用来修复 bug。通常情况下,紧急修复的发布相对简单,在 Bug 修复并测试完成后,可直接合并到 master 进行发布。发布完成后在 master 打上 tag 记录此次发布的版本,并将 hotfix 合并到 develop。
Workflow
对于工作流,用图来表示会更容易理解,如下图:
图中就是我们使用 Git Flow 工作时的流程。很明显,Git Flow 需要用到很多分支,这也是很多开发者放弃它的理由。对于 Git Workflow 还有其他的选择,比如:GitLab Flow 和 GitHub Flow。当然你也可以根据实际的业务场景使用自己的工作流,方式不同,但都是为了同样的目的。