来来来,要上线了,把不需要上线的功能都注释掉。

这个操作让人有点不可思议。


原本我以为,程序员应该都会用 Git!可是,我发现我错了。

Git

Git 是用来做版本管理的,在使用之前,你可能需要先安装它。但通常情况下是不需要的,因为它真的太重要了,所以大部分的操作系统默认都已经安装过了。

Repository

对于 Git 仓库,有以下两种类型:

  • 本地仓库,可以理解为保存在某台主机上不共享的 Git 仓库
  • 远程仓库,保存在远程服务器上的 Git 仓库

一点思考

我想,一些程序员不使用版本管理工具(Git)来管理代码肯定是有原因的,比如说:

  • 一个人开发必有必要;
  • 感觉没什么用,用不用都没什么影响。

有句话好像是这样说的:“失败的原因各种各样,但成功的原因却大致相同”。我们可以思考一下下面的问题:

  • 若你的代码只是保存在电脑上,要是需要在家修改代码怎么办?你不见得去哪都带着电脑吧!万一你用的电脑是台式机,那就尴尬了。
  • 在两周的迭代后,我们发布了新的版本,却发现新的版本存在 Bug,老板要求回到上一个稳定版本。
  • 你可能会还会遇到这样的情况,团队的开发人员在 master 分支上开发的好好的,却接到客服或运营的 Bug 反馈,这时候你要改 Bug 并发布,但是新开发的功能还没开发完。

这里只介绍 Git 解决的三个主要问题,当然 Git 的功能远不止这些,但这三点是必须要搞明白的。

Workflow

分支管理是 Git 的强大功能,在实际的开发中能解决很多问题。而每个人对分支管理的理解是不同,也就会产生很多种分支管理方法。比如说:有的程序员只使用一个 Master 分支,开发、测试、发布、维护(Bug 修复)都在 Master 分支上完成。这样做必定会产生很多问题。

分支管理的主要目的是:满足整个研发过程中(开发、测试、发布、维护),代码的版本控制。这就需要我们在做分支管理的时候,去决策需要使用多少分支,每个分支分别需要做什么事情,以及什么时候创建/合并分支。而这些就是 Git 的工作流,是我们在整个研发过程中使用 Git 来管理代码的流程和规范。

对于 Git 工作流,常用的主要有三种,如:

  • Git Flow
  • GitLab Flow
  • GitHub 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 Workflow:Git Flow-LMLPHP

01-29 17:09