Day29｜常见的三种工作流程 - Git flow、GitHub Flow 与 Gitlab Flow

在制作专案时，大多都是与他人共同协作，当一起开发的人越来越多时，就更需要有一套规则或模式来进行合作，以防多人同时合作时，大家都各自照着自己的方式随便进行，可能会造成合作上的灾难，专案也容易混乱不够清楚。

因此这套有规范的工作流程，在英文里可以称作是 " workflow " 或是 " flow " ，意指水流，这里用来比喻像水流一样，能够顺畅地流动，不会产生冲突、水花。

常见的开发流程：

1. Git flow
2. GitHub Flow
3. Gitlab Flow

上述三套流程，大致上都有一个共同点，就是他们都是以特性驱动开发 (Feature-driven development，简称 FDD)，是一个模型驱动(model-driven)、短期迭代(short-iteration)的过程，过程中会有起点与终点。

起点是需求，先有了需求後，再开启 Feature branch 或 Hotfix branch ，当完成专案以後，将分支的更新合并到原先的分支上（主分支），出来的分支再被删除。

Git flow

是最早出现的一套流程，且广泛被应用。

Git flow 提出不同的分支功能，分别有 master、develop 、hotfix、release、feature 五种分支。

而这五个分支，根据他们的性质，又有其他称法：

• 长期分支 - master 分支、develop 分支

  原因：因 Master 与 Develop 分支会一直存活在整个 Git flow 里，并不会被删除掉。

• 短期分支 - hotfix 分支、release 分支、feature 分支

  原因：当完成专案後，这些更新的版本都会被合并进 Master 或 Develop 分支 ，之後就会被删除掉。

分支应用情用

Master 分支

master 是当 Git 建立版本控制时，就预设的分支，主要用来放稳定、随时可上线的版本。

• 永远处在 production-ready 状态
• 来源是从其他分支合并过来，开发者不会直接 Commit 到此分支上。
• 因为是稳定版本，所以通常会在 master 分支上的 Commit 贴上「 版本标签 」。

Develop 分支

作为主要开发的分支，是所有短期分支的基础分支。

• 最新的下次发布开发状态

• Feature 分支从 Develop 分支切出去，当功能完成後，在合并回来 Develop 分支。

• 创建 Develop 分支的指令：

  $ git checkout -b develop master
  

• 当要发布时，在 Master 分支上对 Develop 分支进行合并：

  $ git checkout master # 切换到 master 分支
  $ git merge --no-ff develop # master 分支对 develop 分支进行合并
  

  -no-ff 参数代表不要快转模式（fast-forward），会额外产生一个 Commit 物件。

--

Hotfix 分支

主要功能是用来进行修复

• 从 Master 分支切出来的。
• 当修复完後，会合并回 Master 分支， 也同时会合并回 Develop 分支。

👉 合并回 Develop 分支的原因：

更新 Develop 分支的版本，避免遇到将 Develop 分支并回 Master 分支时，同样的问题又出现。

👉 避免直接从 Develop 分支切出 Hoxfix 分支的原因：

Develop 分支为功能开发阶段的分支，如果直接从 Develop 分支切 Hotfix 分支，再合并回 Master 分支，可能会造成管理上的问题/灾难。

• 建立一个 Hotfix 分支

  $ git checkout -b fixbug-0.1 master
  

  常用 fixbug-* 的形式命名

• 修补结束後，合并到 Master 分支

  $ git checkout master # 切换到 master 分支
  $ git merge --no-ff fixbug-0.1 # 搭配非快转模式参数合并 hotfix 分支
  $ git tag -a 0.1.1 # 贴上讯息标签
  

• 同时也要再合并到 Develop 分支

  $ git checkout develop # 切换到 develop 分支
  $ git merge --no-ff fixbug-0.1 # 搭配非快转模式参数合并 hotfix 分支
  

• 最後再将 Hotfix 分支删除

  $ git branch -d fixbug-0.1 # 删除 fixbug-0.1 分支
  

  -d 参数为删除之意

Release 分支

在 Develop 分支发布正式版本到 Master 分支之前，可以先进行一个预备发布的本版本进行测试。

• 从 Develop 分支切出来

• 完成後需合并到 Master 分支与 Develop 分支

  👉 为何又需要再合并 Develop 分支？

  Master 分支为上限版本，而合并 Develop 分支的原因是为了後续可能 Release 分支上还会侦测到其他问题，所以需与 Develop 分支同步，以防再度出现同样的问题。

• 建立 Release 分支

  $ git checkout -b release-1.2 develop
  

  release-* 的形式命名

• 修正完成後，合并到 Master 分支

  $ git checkout master # 切换到 master 分支
  $ git merge --no-ff release-1.2 # 合并 release-1.2 分支，使用非快转模式合并
  $ git tag -a 1.2 # 为新的节点新增讯息标签
  

• 之後也要记得合并到 Develop 分支上

  $ git checkout develop # 切换到 develop 分支
  $ git merge --no-ff release-1.2 # 合并 release-1.2 分支，使用非快转模式合并
  

• 两个长期分支都合并完後，再删除掉 Release 分支

  $ git branch -d release-1.2
  

Feature 分支

主要用来新增功能的分支。

• 都是从 Develop 分支切出来的，完成後再合并回 Develop 分支。

• 建立一个 Feature 分支

  $ git checkout -b feature-x develop
  

  feature-* 的形式命名

• 功能开发完成後，再将 Feature 分支合并到 Develop 分支上

  $ git checkout develop # 切换到 develop 分支
  $ git merge --no-ff feature-x # 合并 feature-x 分支，使用非快转模式合并
  

• 同样完成後，会删除掉分支

  $ git branch -d feature-x # 删除 feature-x 分支
  

Git flow 的优缺点

优点：

清晰可控

缺点：

较为复杂，需要同时维护 master 分支与 delevop 分支两个长期分支。因为通常都以 master 分支当作正式发布的分支，而 delevop 分支是进行开发的分支，会时常需要切换。

Github flow

Git flow 的简化版。

• 只有一个长期分支 - master 分支
• 流程：

  1. 根据需求，从 master 分支切出其他分支进行开发。

  2. 开发完成或是需要讨论时，向 master 分支发起 pull request 请求（PR）

     GitHub 有 PR 功能，可以用於可能你想帮其他人提供更好的程序码，就可以发起 PR 请求。

  3. Pull request 请求被接受，後合并到 master ，重新部署後，原先的分支则被删除。

--

Github flow 的优缺点

优点：

简单、适用於「持续更新」的产品的开发流程

缺点：

预设情况为 master 为最新的提交版本，但这造成有时可能有指定时间发布，或是尚须审核，则这时候只有一个 master 分支就会造成困扰，需新建一个 production 分支追踪线上版本。

Gitlab flow

Git flow 与 GitHub flow 的合并模式流程。

• 原则：以「上游优先」（upsteam first）。意指只认存在一个主要分支 Master 分支，他是其他所有分支的「上游」。只有这只上游分支采纳的代码变化，才能应用到其他分支。
• 针对不同的开发情况，有两种情况：
  1. 「持续发布」- 除了 master 分支外，根据不同环境建立对应的分支。并需服从上游到下游一层一层的过关规则。
  2. 「版本发布」- 每当有一个稳定的版本，就要从 master 分支拉出一个分支。只有修补 Bug 时，才允许将代码合并到这些分支，并且需要更新小版本号。

没有哪一种模式的流程比较好，都是根据情况或是各公司的开发模式来决定流程规则。因此这几种常见的流程都可以仔细研究，对於後续的专案管理上也更好与他人协作。

参考文章：

https://www.ruanyifeng.com/blog/2012/07/git.html

https://www.ruanyifeng.com/blog/2015/12/git-workflow.html