【Day19】Git 版本控制 - 多人协作 GitHub Flow

Git Flow 的缺点可以参考 git flow 实战经验谈 part1 - 别再让 gitflow 拖累团队的开发速度这篇文章，里面很详细的解释 Git Flow 的缺点，我从文章中节录了几个 Git Flow 缺点：

• gitflow 将流程建立在 develop 之上是不必要的，也是所有问题的根源，应单纯以 master 为主。
• gitflow 要求 hotfix 及 release 需要分别 merge 进去 master 及 develop。这个想法制造了相当多不必要的 merge 动作。这边正确的原则应跟前一点一样，全部透过 master 来同步比较简洁。
• 从尚未出版的 develop 建立分支，有可能会造成在每次出版周期中应该各自独立的分支间产生不必要的相依性。
• develop 分支是由 master 长出来的，所以不要再有 master 不能 merge 进去 develop 这种想法。

创建 Git Flow 的作者说：GitHub Flow 是更简单好用的流程，而官方给予的解释如下：

GitHub flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly. This guide explains how and why GitHub flow works.

其实 GitHub Flow 和 Git Flow 最大的差异在於不需要一次建立 5 个分支，而是在需要这个功能时，再创建 feature 分支，经过一个 SOP 确认完没问题後，再 merge 到 Master 分支上。而且在 GitHub Flow 中 Master 是可以被部署的，不像 Git Flow 是不能动的版本。

那麽，上述说的 SOP 是什麽呢？

图片从 GitHub Guides 改编

如上图，主要可以分成 6 个步骤，分别为：

• Create a branch
• Add commits
• Open a Pull Request
• Discuss and review your code
• Deploy
• Merge

GitHub Flow SOP

Create a branch

当你想要建立一个新的功能或是修改时，就新增一个分支，在通过 Deploy 前这个分支上的修改不会影响到 Master 上的程序。

而官方也有提到：There's only one rule: anything in the main branch is always deployable.

所以无论你是要新增、修补功能都可以从 Master 分支上拉出，而且命名要具有可读性，这样团队的其他人才会知道这条分支是在负责什麽样的事情。

Add commits

创建分支後就可以开始进行修改了！而每次在进行修改、新增、删除都是在进行 commit 这个动作，这些 commit 也都会被记录到你的 branch 下。
˙是
commit 的内容也很重要，就像程序码的注解一样，可以让团队成员更快看懂你这个分支主要在进行什麽任务，增加可读性。

Open a Pull Request

当你完成任务後想要 merge 回 Master 就要先发起 Pull Request(简称：PR)，这个功能在 Fork 篇有提及过，所以就不赘述了，主要就是要发起 PR 等待对方同意你的 branch merge 到 Master 这样。

Discuss and review your code

当你发起 Pull Request 後，团队的成员或许会对你的程序有问题，这时就可以一起讨论有疑问的部分，并且再进行修改。

Deploy

或许你更常听到的是他的中文名字「部署」，就是在合并之前再进行一次最终测试，以免发生问题。

Merge

当上述流程都完成後，就可以 Merge 回 Master 了！
Merge 後会保留对程序的修改纪录，以供未来参考使用。

上述就是 GitHub Flow 的整个流程，相较於 Git Flow 而言减少了许多分支的定义，更轻量化、简单易懂。

Reference

git flow 实战经验谈 part1 - 别再让 gitflow 拖累团队的开发速度
Understanding the GitHub flow