<rp id="kbk7q"></rp><th id="kbk7q"><track id="kbk7q"></track></th>
<dd id="kbk7q"></dd><progress id="kbk7q"><pre id="kbk7q"></pre></progress>

  • <th id="kbk7q"><pre id="kbk7q"><sup id="kbk7q"></sup></pre></th>

  • <dd id="kbk7q"><pre id="kbk7q"></pre></dd>

    <rp id="kbk7q"></rp>
  • 您的位置:知識庫 ? 軟件工程

    Git協作流程

    作者: 阮一峰  發布時間: 2015-12-29 16:29  閱讀: 19052 次  推薦: 64   原文鏈接   [收藏]  

      Git 作為一個源碼管理系統,不可避免涉及到多人協作。

      協作必須有一個規范的流程,讓大家有效地合作,使得項目井井有條地發展下去。"協作流程"在英語里,叫做"workflow"或者"flow",原意是水流,比喻項目像水流那樣,順暢、自然地向前流動,不會發生沖擊、對撞、甚至漩渦。

      本文介紹三種廣泛使用的協作流程:

    • Git flow
    • Github flow
    • Gitlab flow

      如果你對Git還不是很熟悉,可以先閱讀下面的文章。

      一、功能驅動

      本文的三種協作流程,有一個共同點:都采用"功能驅動式開發"(Feature-driven development,簡稱FDD)。

      它指的是,需求是開發的起點,先有需求再有功能分支(feature branch)或者補丁分支(hotfix branch)。完成開發后,該分支就合并到主分支,然后被刪除。

      二、Git flow

      最早誕生、并得到廣泛采用的一種協作流程,就是Git flow 。

      2. 1 特點

      它最主要的特點有兩個。

      首先,項目存在兩個長期分支。

    • 主分支master
    • 開發分支develop

      前者用于存放對外發布的版本,任何時候在這個分支拿到的,都是穩定的分布版;后者用于日常開發,存放最新的開發版。

      其次,項目存在三種短期分支。

    • 功能分支(feature branch)
    • 補丁分支(hotfix branch)
    • 預發分支(release branch)

      一旦完成開發,它們就會被合并進developmaster,然后被刪除。

      Git flow 的詳細介紹,請閱讀我翻譯的中文版《Git 分支管理策略》

      2. 2 評價

      Git flow的優點是清晰可控,缺點是相對復雜,需要同時維護兩個長期分支。大多數工具都將master當作默認分支,可是開發是在develop分支進行的,這導致經常要切換分支,非常煩人。

      更大問題在于,這個模式是基于"版本發布"的,目標是一段時間以后產出一個新版本。但是,很多網站項目是"持續發布",代碼一有變動,就部署一次。這時,master分支和develop分支的差別不大,沒必要維護兩個長期分支。

      三、Github flow

      Github flow 是Git flow的簡化版,專門配合"持續發布"。它是 Github.com 使用的協作流程。

      3. 1 流程

      它只有一個長期分支,就是master,因此用起來非常簡單。

      官方推薦的流程如下。

      第一步:根據需求,從master拉出新分支,不區分功能分支或補丁分支。

      第二步:新分支開發完成后,或者需要討論的時候,就向master發起一個pull reqest(簡稱PR)。

      第三步:Pull Request既是一個通知,讓別人注意到你的請求,又是一種對話機制,大家一起評審和討論你的代碼。對話過程中,你還可以不斷提交代碼。

      第四步:你的Pull Request被接受,合并進master,重新部署后,原來你拉出來的那個分支就被刪除。(先部署再合并也可。)

      3. 2 評價

      Github flow 的最大優點就是簡單,對于"持續發布"的產品,可以說是最合適的流程。

      問題在于它的假設:master分支的更新與產品的發布是一致的。也就是說,master分支的最新代碼,默認就是當前的線上代碼。

      可是,有些時候并非如此,代碼合并進入master分支,并不代表它就能立刻發布。比如,蘋果商店的APP提交審核以后,等一段時間才能上架。這時,如果還有新的代碼提交,master分支就會與剛發布的版本不一致。另一個例子是,有些公司有發布窗口,只有指定時間才能發布,這也會導致線上版本落后于master分支。

      上面這種情況,只有master一個主分支就不夠用了。通常,你不得不在master分支以外,另外新建一個production分支跟蹤線上版本。

      四、Gitlab flow

      Gitlab flow 是 Git flow 與 Github flow 的綜合。它吸取了兩者的優點,既有適應不同開發環境的彈性,又有單一主分支的簡單和便利。它是 Gitlab.com 推薦的做法。

      4. 1 上游優先

      Gitlab flow 的最大原則叫做"上游優先"(upsteam first),即只存在一個主分支master,它是所有其他分支的"上游"。只有上游分支采納的代碼變化,才能應用到其他分支。

      Chromium項目就是一個例子,它明確規定,上游分支依次為:

    1. Linus Torvalds的分支
    2. 子系統(比如netdev)的分支
    3. 設備廠商(比如三星)的分支

      4. 2 持續發布

      Gitlab flow 分成兩種情況,適應不同的開發流程。

      對于"持續發布"的項目,它建議在master分支以外,再建立不同的環境分支。比如,"開發環境"的分支是master,"預發環境"的分支是pre-production,"生產環境"的分支是production

      開發分支是預發分支的"上游",預發分支又是生產分支的"上游"。代碼的變化,必須由"上游"向"下游"發展。比如,生產環境出現了bug,這時就要新建一個功能分支,先把它合并到master,確認沒有問題,再cherry-pickpre-production,這一步也沒有問題,才進入production

      只有緊急情況,才允許跳過上游,直接合并到下游分支。

      4. 3 版本發布

      對于"版本發布"的項目,建議的做法是每一個穩定版本,都要從master分支拉出一個分支,比如2-3-stable2-4-stable等等。

      以后,只有修補bug,才允許將代碼合并到這些分支,并且此時要更新小版本號。

      五、一些小技巧

      5. 1 Pull Request

      功能分支合并進master分支,必須通過Pull Request(Gitlab里面叫做 Merge Request)。

      前面說過,Pull Request本質是一種對話機制,你可以在提交的時候,@相關人員團隊,引起他們的注意。

      5. 2 Protected branch

      master分支應該受到保護,不是每個人都可以修改這個分支,以及擁有審批 Pull Request 的權力。

      Github 和 Gitlab 都提供"保護分支"(Protected branch)這個功能。

      5. 3 Issue

      Issue 用于 Bug追蹤和需求管理。建議先新建 Issue,再新建對應的功能分支。功能分支總是為了解決一個或多個 Issue。

      功能分支的名稱,可以與issue的名字保持一致,并且以issue的編號起首,比如"15-require-a-password-to-change-it"。

      開發完成后,在提交說明里面,可以寫上"fixes #14"或者"closes #67"。Github規定,只要commit message里面有下面這些動詞 + 編號,就會關閉對應的issue。

    • close
    • closes
    • closed
    • fix
    • fixes
    • fixed
    • resolve
    • resolves
    • resolved

      這種方式還可以一次關閉多個issue,或者關閉其他代碼庫的issue,格式是 username/repository#issue_number

      Pull Request被接受以后,issue關閉,原始分支就應該刪除。如果以后該issue重新打開,新分支可以復用原來的名字。

      5. 4 Merge節點

      Git有兩種合并:一種是"直進式合并"(fast forward),不生成單獨的合并節點;另一種是"非直進式合并"(none fast-forword),會生成單獨節點。

      前者不利于保持commit信息的清晰,也不利于以后的回滾,建議總是采用后者(即使用--no-ff參數)。只要發生合并,就要有一個單獨的合并節點。

      5. 5 Squash 多個commit

      為了便于他人閱讀你的提交,也便于cherry-pick或撤銷代碼變化,在發起Pull Request之前,應該把多個commit合并成一個。(前提是,該分支只有你一個人開發,且沒有跟master合并過。)

      這可以采用rebase命令附帶的squash操作,具體方法請參考我寫的《Git 使用規范流程》

      (完)

    64
    0
    標簽:git

    軟件工程熱門文章

      軟件工程最新文章

        最新新聞

          熱門新聞

            中文大香蕉在线影院