Git 協同開發 — Workflow

Workflow(工作流程) 主要是讓多人協作能順利的進行,減少衝突的發生。目前由於團隊規模很小,因此採用簡單、能持續部署的 GitHub Flow,將來開發者增加再採用嚴謹的 Git Flow

另外,如果有團隊外的夥伴想要貢獻程式碼,會讓他們以 Fork and Pull Request 模式協作。


GitHub Flow ★

上面那條為 master 分支,下面則是 feature 分支

這種工作流程的主要分支(branch)是 master,作為 產品發布 用,它是 穩定 且 可部署的。重點是,不能直接在 master 上做修改。以 master 為基底,任何人在做開發時都應該新建額外的暫時性分支 (feature, bugfix, hotfix, etc.)。

當成員要將新的代碼合併回 master,不能在 master 上執行 git merge my-feature-branch,而是要在 GitHub 發送 Pull Request。當 Project Manager (PM) 透過 pull request 審閱過這次的更改 (commit),確認沒問題了,才由 PM 合併回 master。 所以 pull request 有 code review 和 開發討論版 這兩種功用。由上述可知,成員能在 master 上做的事只有從 remote 端拉回更新 (pull)。

下表列出 PM 和 成員對於 master 分支的權限:


Git Flow

from http://nvie.com/posts/a-successful-git-branching-model/

Git Flow 相較於 GitHub Flow 多了一個主要分支,develop。而其它暫時性分支除了上述的兩種以外又多了 release。 一般開發中的變更會從 feature 整合到 develop,等到功能有了一定程度的完善後,就會從 develop 開一個 release 分支, 代表某一版本即將釋出。Release 分支不會再去合併新的 feature,此分支僅僅用來測試及修正,修正的 commits 也可以合併回 develop。 一切測試都通過後,最終在合併到 master,該版本就可以直接部署了。

產品發佈後,也許客戶發現某些問題,需要緊急修改,這時可以從 master 額外開一個 hotfix 分支來修補,問題解決後再合併回 master 與 develop。

所以分支的相依性以兩個主幹 master 和 develop 來看,會是:

分出去 ( →):

  • master → develop, hotfix
  • develop → feature, release

合併回 (←):

  • master ← release, hotfix
  • develop ← feature, release (only bugfix), hotfix

Fork and Pull Request

from http://www.slideshare.net/yfain/princeton-jug-gitgithub

這種協作模式跟上面兩種不一樣。開發者不直接 clone 主專案,而是去 fork 它。後者會直接將源專案拷貝到你的 GitHub 帳戶下,而你對拷貝的那份將有完整的控制權。反之,如果是 clone 源專案,除非你是 collaborator,不然是沒有 push 權限的。

開發者可以在 fork 的專案中隨意的更改,當你想要貢獻自己的成果給源專案時,就必須向源專案的主持人發送 pull request,審閱合格後,你的貢獻就會 合併回源專案。這是種相對安全的工作流程。

但這種模式有個小麻煩,fork 的那份要與原專案同步更新需要額外的設定


GitHub Flow vs. Git Flow

由上面說明可以體會,Git Flow 因需要永久地維護兩個主分支,且又有許多暫時性分支的類型,不利於初期開發,因此才先採用 GitHub Flow。

但會提到 Git Flow 而且會想在 開發後期 採用,其實有另一層考量:以產品類型來說,GitHub Flow 允許將開發進度直接整合到 master,所以適合 網站 這種常常需要更新的服務。

但考慮到我們是做 mobile app,之後必定會發布到 Google Play 或 AppStore,如果套用 GitHub Flow 就會有個問題:

假設目前正好發布某個版本,當一切都穩妥地合併到 master 之後,就部署到 store 上了,而且是 AppStore 哦。大家都知道 Apple 的審查灰常嚴格,常常一拖就是一陣子,但我們的團員仍在開發,如果他們將 commits 合併到 master 分支會造成部署的問題,但不合併,成員彼此之間又沒法協同開發,因此就造成兩難的局面。

而這一切的根源正是我們 只有一個主分支 — master。而 Git Flow 的 develop 分支正好能作為 緩衝區 來解決上述問題。

Like what you read? Give KuanYu Chu a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.