您好,登錄后才能下訂單哦!
這篇文章將為大家詳細講解有關Git的工作流程是怎樣的,文章內容質量較高,因此小編分享給大家做個參考,希望大家閱讀完這篇文章后對相關知識有一定的了解。
Git 作為一個源碼管理系統,不可避免涉及到多人協作。
協作必須有一個規范的工作流程,讓大家有效地合作,使得項目井井有條地發展下去。"工作流程"在英語里,叫做"workflow"或者"flow",原意是水流,比喻項目像水流那樣,順暢、自然地向前流動,不會發生沖擊、對撞、甚至漩渦。
這里介紹三種廣泛使用的工作流程:
Git flow
Github flow
Gitlab flow
如果你對Git還不是很熟悉,可以先閱讀下面的文章。
《Git 使用規范流程》
《常用 Git 命令清單》
《Git 遠程操作詳解》
本文的三種工作流程,有一個共同點:都采用"功能驅動式開發"(Feature-driven development,簡稱FDD)。
它指的是,需求是開發的起點,先有需求再有功能分支(feature branch)或者補丁分支(hotfix branch)。完成開發后,該分支就合并到主分支,然后被刪除。
最早誕生、并得到廣泛采用的一種工作流程,就是Git flow 。
它最主要的特點有兩個。
第一步:根據需求,從
master
拉出新分支,不區分功能分支或補丁分支。第二步:新分支開發完成后,或者需要討論的時候,就向
master
發起一個pull request(簡稱PR)。第三步:Pull Request既是一個通知,讓別人注意到你的請求,又是一種對話機制,大家一起評審和討論你的代碼。對話過程中,你還可以不斷提交代碼。
第四步:你的Pull Request被接受,合并進
master
,重新部署后,原來你拉出來的那個分支就被刪除。(先部署再合并也可。)
Github flow 的最大優點就是簡單,對于"持續發布"的產品,可以說是最合適的流程。
問題在于它的假設:master
分支的更新與產品的發布是一致的。也就是說,master
分支的最新代碼,默認就是當前的線上代碼。
可是,有些時候并非如此,代碼合并進入master
分支,并不代表它就能立刻發布。比如,蘋果商店的APP提交審核以后,等一段時間才能上架。這時,如果還有新的代碼提交,master
分支就會與剛發布的版本不一致。另一個例子是,有些公司有發布窗口,只有指定時間才能發布,這也會導致線上版本落后于master
分支。
上面這種情況,只有master
一個主分支就不夠用了。通常,你不得不在master
分支以外,另外新建一個production
分支跟蹤線上版本。
Gitlab flow 是 Git flow 與 Github flow 的綜合。它吸取了兩者的優點,既有適應不同開發環境的彈性,又有單一主分支的簡單和便利。它是 Gitlab.com 推薦的做法。
Gitlab flow 的最大原則叫做"上游優先"(upsteam first),即只存在一個主分支master
,它是所有其他分支的"上游"。只有上游分支采納的代碼變化,才能應用到其他分支。
Chromium項目就是一個例子,它明確規定,上游分支依次為:
Linus Torvalds的分支
子系統(比如netdev)的分支
設備廠商(比如三星)的分支
Gitlab flow 分成兩種情況,適應不同的開發流程。
對于"版本發布"的項目,建議的做法是每一個穩定版本,都要從master
分支拉出一個分支,比如2-3-stable
、2-4-stable
等等。
以后,只有修補bug,才允許將代碼合并到這些分支,并且此時要更新小版本號。
前面說過,Pull Request本質是一種對話機制,你可以在提交的時候,@
相關人員或團隊,引起他們的注意。
master
分支應該受到保護,不是每個人都可以修改這個分支,以及擁有審批 Pull Request 的權力。
Github 和 Gitlab 都提供"保護分支"(Protected branch)這個功能。
Issue 用于 Bug追蹤和需求管理。建議先新建 Issue,再新建對應的功能分支。功能分支總是為了解決一個或多個 Issue。
功能分支的名稱,可以與issue的名字保持一致,并且以issue的編號起首,比如"15-require-a-password-to-change-it"。
這可以采用rebase
命令附帶的squash
操作。
關于Git的工作流程是怎樣的就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。