Git workflow 詳談

時間 2019-11-15

標籤 git workflow 詳談欄目 Git 简体版

原文原文鏈接

做爲一名工程師， Git 在平常開發中是不可或缺的工具。
這裏詳細介紹幾種比較經常使用的基於 Git 的工做流模型, 以便於團隊協做的規範化和效率提高。git

中心化工做流

使用過SVN的應該都知道， SVN使用的是集中式管理流程，若是你剛從SVN 切換到 Git ，你能夠嘗試使用中心化工做流的方式。這樣，你幾乎不須要變動以前的工做方式，就能夠完成平滑的過渡了。並且在使用過程當中還能夠看到 Git 優於 SVN 的地方：
第一，每一個成員均可以在本地擁有一份完整的項目代碼倉庫，而不僅是一個工做區的副本，任何人均可以在本地執行 add 和 commit ，而不須要考慮遠端倉庫是否有變動，直到須要的時候再去提交便可。
第二，Git 的工做區、暫存區、引用更新等設計，能夠給開發者更多自由來切換當前工做，且不會形成代碼丟失。程序員

工做細節

中心化工做流的方式是：在遠端（遠端能夠是服務器端，也能夠是本地的任意目錄）新建一個倉庫，默認是 master 分支，做爲惟一的中心倉庫。全部人都 clone 這個倉庫做爲本地倉庫，並在本地倉庫進行開發。本地的提交是和遠端倉庫無關的，等須要的時候再 push 進主倉庫的 master 分支便可。bash

在這種方式下，遠端是惟一肯定的中心倉庫，全部人都要以這個倉庫爲準。因此，在提交以前要先 fetch 最新提交，在這些提交之上做出本身的更改(通常咱們使用 rebase來完成)。服務器

若是本地的修改和遠端倉庫中的變動發生了衝突，那麼 Git 會暫停 rebase ，並讓你來解決這些衝突。咱們能夠很簡單的使用 git status 和 git add 等命令完成衝突的合併。另外, 若是咱們解決不了衝突, 咱們也可使用 git rebase --abort 很容易的退出 rebase 的過程。工具

這樣天天的工做方式就變成了，從中心倉庫拉取最新代碼，而後開始一天的工做，開發完成後，拉取中心倉庫的更新，合併代碼後，再提交至中心倉庫，結束一天的工做。這樣的好處就是不須要變動原先（使用SVN）的工做方式。固然弊端也很明顯，你並不知道中心倉庫的代碼是不是穩定的，或者說並不能肯定當你的代碼和中心倉庫代碼合併後，是不是穩定的，帶來的問題就是開發進度和回滾不那麼方便控制。post

示例

咱們有兩位程序員, A 和 B, 兩人同時在對一個項目作開發, 而且使用 Git 的中心化工做流方式。測試

1.建立遠端中心倉庫fetch

這裏咱們有兩種方式： ui

藉助於已經搭建好的平臺 GitHub/GitLab 之類的，點擊 create repo 便可。spa
在遠端(這裏只是爲了區別本地倉庫，事實上，使用任何一個其餘人能夠連通的機器均可以,包括本身本地其餘目錄) 建立一個 裸倉庫 ，建立裸倉庫和咱們平時建立本地倉庫的區別，能夠參考我另外一篇文章 Git 本地倉庫和裸倉庫。

這裏以第二種方式爲例：

# --bare 參數必須有
git init --bare /the/repo/path.git複製代碼

2.全部人都 clone 中心倉庫到本地做爲本地倉庫

git clone /the/repo/path.git複製代碼

注意倉庫地址必須是正確的，且有權限訪問才能 clone 成功。

3.程序員 A 在他的本地倉庫進行功能開發並進行發佈

通常狀況下，咱們經過 git status 看看當前狀態，並經過 git add 和 git commit 等命令完成本地倉庫的提交。固然這個提交影響的也只是本地倉庫而已，並無對中心倉庫產生任何影響，因此咱們既不須要關心別人有什麼提交，也不用擔憂咱們當前的提交是否對別人形成了影響。當 A 認爲本身所開發的功能已經完成，那他將執行 git push origin master 這樣的操做，將本身本地倉庫全部不存在於中心倉庫的提交都 push 到遠端的中心倉庫上。

4.程序員 B 在他本地倉庫進行功能開發

B 在 clone 中心倉庫後所作的操做和 A 同樣，在本地倉庫進行項目開發，並在本地倉庫進行提交，他不須要知道中心倉庫發生了什麼樣的變化。

5.程序員 B 將本身開發的功能並進行發佈

B 在確認本身開發的功能已經完成後，想要將本身的代碼經過 git push origin master 這樣的操做發佈至中心倉庫，可是卻被中心倉庫提示他的修改已經和中心倉庫有了分叉，須要他先執行 git pull 之類的操做，將中心倉庫上 A 的提交與 B 本地的提交進行合併才容許他併入中心倉庫。因此，他執行了 git pull --rebase origin master 來將中心倉庫的修改併入他的本地倉庫。使用 --rebase 參數的意義在於 fetch 執行完成後，將把 B 的全部提交移至 master 頂端。

固然這裏不使用 --rebase 參數也會成功，只不過是會生成一個合併提交，有些狀況下使用 --ff 參數也能夠避免產生合併提交。在這裏使用 --rebase 只是一個建議操做。

若是 A 和 B 修改的文件沒有關聯，通常狀況下會直接完成合並，若是發生衝突，Git 將會暫停 rebase 的過程，並列出當前衝突的文件，你能夠簡單的使用 git status 和 git add 等命令進行合併，合併後使用 git rebase --continue 繼續 rebase 的過程。或者使用 git rebase --abort 退出 rebase 過程。

在 B 合併完成後，能夠執行 git push origin master 將本身開發的功能發佈至中心倉庫。

至此，基礎的中心化工做流方式就介紹完了，可是這裏也很容易看出來其中的問題，除了前面說到過的之外，還有就是效率低下，若是不少人都在持續進行提交，那很影響新功能的提交（多人持續性進行提交）。一個比較容易提高效率的方式就是切換到特性分支工做流的方式。

特性分支工做流

基於特性的分支工做流，能夠爲每一個特性作隔離，避免對中心倉庫主幹代碼形成影響。

工做細節

顧名思義，就是根據每一個特性都會開一個新的分支，每一個分支都應該包含着描述性的名稱，不管是一我的開發，仍是多人協同，該特性的所有開發工做都在這個分支上進行。待該特性開發完成後，併入主分支，而後刪除分支，代碼上線。

這種狀況下，最大的優點在於，全部的特性開發均可以並行處理。沒必要要像中心化工做流方式，每一個人的變更均可能引發其餘的人的代碼合併，而且全部功能都雜糅在一塊兒，從測試和回滾都會變得很繁瑣。另外的一個好處就是特性分支能夠推送到中心倉庫，這樣也便於單獨測試。

這裏須要注意的是，特性分支往主分支合併的時機，應該是該特性開發完成，並測試經過，避免對主幹代碼形成污染。

在進行分支隔離後，咱們發現，咱們當前只處理了開發模式，但並無涵蓋一個很完備的產品生命週期，開發、發佈、維護等過程，因此，咱們有了 Gitflow 工做流。

Gitflow 工做流

基於Gitflow 的工做流方式，這種工做流方式，主要是管理着新功能開發，發佈及維護等模式，根據不一樣類型的工做對分支進行定義，分爲 特性分支 ，修復分支，release 分支，開發分支 和 主分支 。

主分支：中心倉庫創建後的默認 master 分支（固然使用其餘分支也能夠，但要保證該分支是受保護的）。主分支隨時保持代碼是穩定的，而且有明確的版本標籤，後續代碼回滾等操做都將從主分支進行。

開發分支：中心倉庫創建後，從 master 分支切出來，此時與 master 分支保持一致。後續演進中，開發分支隨時保持代碼最新，但卻不必定是線上實際運行的代碼。

git checkout -b develop複製代碼

特性分支：應該從開發分支切出，開發完成後，再合併進入開發分支，若是達到了發佈標準，則從開發分支切出 release 分支，切出來的這個分支，只作該版本內的代碼修復，再也不加入新功能，這時此分支處於鎖定的狀態。

修復分支，用於對線上主分支代碼的及時修復，待修復完成後，合併進入主分支，再併入開發分支。修復分支只能從主分支切出。

發版分支，通常命名爲 release-xxx 這個分支只能從開發分支切出，最後併入主分支，打上版本號的標籤，它也應該併入開發分支，若是中間有其餘修復的話。

fork 工做流

fork 分支流和上面介紹的全部工做流都不太同樣。它的上游有一個惟一倉庫，全部人都是 fork 這個倉庫，在本身的遠端和本身的本地各維護一個倉庫，待開發完成後推入本身的遠端倉庫，並結合 GitHub/GitLab等提交 Pull Request，進入了 review 階段，待經過後，將會被合併入上游惟一的倉庫。這種方式比較適合 GitHub 中的大型開源項目，對於小團隊的內部項目，這種方式可能未必合適。
並且 fork 工做流，會佔用更多的資源（畢竟每一個人都維護一份遠端倉庫）。並且每一個人都看不到其餘人的動態，只有當提交 Pull Request 的時候，才知道每一個人發生了什麼。