Day 15 -版本控制与git flow

前十四天我们快速看过了Vue的语法以及一些基本概念，今天我们要跳一下来看何谓版本控制与git flow。

我们在开发专案时，常常会需要与别人共同合作，这时候，版本控制就很重要了，因为总不能你要把你改的程序码交给别人时，打包成一个zip档，这样不仅浪费空间，而且别人也不知道你到底改了甚麽。

在版本控制的世界中，有两大巨头，第一个是git，其次是svn，在这里，Grant选择使用Git作为我们进行版控的工具，相关的git用法，这里就不再多做赘述罗。

目前的版控系统大多以git为主，例如GitHub、Bitbucket、GitLab等等，这里我选择使用Github作为我们储存程序码的地方。

除此之外，我们在开发的流程上，最好是导入git flow，因为这将有助於我们维持开发的独立、简洁性，而甚麽是git flow呢?

让我们来看以下这张图:

在github的repository中，可以被分为许多的branch，这些branch看似独立，却又息息相关。

根据 Git Flow 的建议，主要的分支有 master、develop、hotfix、release 以及 feature 这五种分支，a每种分支负责不同的功能。其中 Master 以及 Develop 这两个分支又被称做长期分支，因为他们会一直存活在整个 Git Flow 里，相当重要，而其它的分支大多会因任务结束而被删除。

接着我们来看看每种分支的功能与特性:

Master 分支

master代表的是整个专案或产品的主线，主要是用来放稳定、随时可上线的版本(Production Version)。因此，这个分支的来源只能从别的分支合并过来，开发者不会直接 Commit 到这个分支。由於是稳定版本，所以当我们完成了一个版本的释出，通常也会在这个分支上的 Commit 上打上版本号标签。

Develop 分支

develop这个分支主要是所有开发的基础分支，当要新增功能(Feature)的时候，所有的 Feature 分支都是从这个分支切出去的，Feature 分支的功能完成後，也都会合并回来这个分支，开发分支存放的是相对稳定，经过开发者测试後没问题，但还需要一些时间多做测试的程序码。

Hotfix 分支

当Production版本的线上产品发生紧急问题的时候，这时候我们会从 Master 分支开一个 Hotfix 分支出来进行修复，意即告诉每个开发者，Production发生问题了!

Hotfix 分支修复完成之後，就会合并回 Master 分支，这时候再将Master的程序码merge back回去 Develop 分支。

在这里大家一定有个疑问，那为什麽一开始不从 Develop 分支切出来修？因为 Develop 分支的功能可能尚在开发中，有些功能或许不是那麽稳定，这时候如果硬是要从这里切出去，只会对线上产品造成更大的灾难喔。

Release 分支

当认为 Develop 分支够成熟了，我们就可以把 Develop 分支合并到 Release 分支，在这边进行算是上线前的最後测试，通常产品会有不同的环境，Test、Beta、Prod等等，而Release版本的程序码我们就会将其释出至Test或Beta版本的环境供user测试。

测试完成後，为了让程序码进行同步，Release 分支将会会合并到 Develop 分支中，再将develop merge进master里。

Feature 分支

当要开始新增功能的时候，就是使用 Feature 分支的时候了。Feature 分支都是从 Develop 分支来的，完成之後会再并回 Develop 分支。

Git flow在软件工程中，Grant个人觉得满重要的，因为简洁的版本控制可以提升合作的效率，间接也能提升工程师们的产能。