碼極系列 | Git主幹與共享分支

咱們在實現團隊協做流程以及 CI/CD 流程時，在很大程度上須要依賴 Git 分支這個功能，此次就來簡單說說經常使用的兩類分支吧。

主幹

通常爲 master 分支，能夠理解爲穩定的，可發佈的，面向生產環境的分支。

咱們的項目通常都是面向生產環境的，也就是說咱們開發的功能最終都會被部署到生產環境，若是說咱們的主幹不是穩定的不是面向生產環境，那這棵「樹」就會越長越歪，離咱們指望的走向愈來愈遠，與生產環境漸行漸遠。

共享分支

視乎於團隊協做流程以及 CI/CD 流程的需求，在有的時候除了主幹之外，還會有專門的共享分支來接受開發人員的提交。

何時使用共享分支？

舉個例子：項目建立之初，咱們爲項目創建 Git 倉庫，默認的咱們獲得了一個 master 分支，在咱們準備好項目了基建（如搭建目錄、文檔等）後，就能夠撰寫第一個提交。在正式進入開發階段以後，能夠基於 master checkout 一個名爲 develop 的分支，以後全部的功能分支都基於 develop checkout，開發好的功能分支再合併到 develop 分支，那麼 develop 就能夠被稱爲共享分支。

在完成某個階段的開發工做後，develop 的改動被確認沒問題以後，會被合併到 master。

你或許會以爲很奇怪，那也沒啥特別的，是的，畢竟不管分支的名字是什麼，它始終都是一個普通的分支而已，你不該該從命名去理解，而是從這個分支的使命去理解，從整個流程上去理解。

搞事情？沒門兒！不當心？不用怕！

我就是要搞事情！我偏要在 master 開發！

哎呦喂，一個不當心在 master 上修改了代碼，要不就偷偷的 push 上去得了！

在 Github 或是 Gitlab 都提供了分支保護功能，能夠將指定的分支設置爲保護分支，這裏就把 master 設置爲保護分支，也就是說即便你在本地的 master 分支修改了內容，但只要你沒有權限，就不可能做用到託管倉庫的 master 分支。

這不就是 xx flow 嗎？

在業界的確已經存在了一些成熟的 flow，若是想更深刻了解比較成熟的 Git 協做流程，能夠查找以下資料：

• Git flow
• Github flow
• Gitlab flow

每一個流程都有各自的特色以及適用場景，若是恰好你所在的團隊或項目適用某種流程，那就用起來吧！若是這些流程都不知足，徹底能夠基於上面的流程去定製出一個符合團隊或項目的流程 ，這裏沒有太多的教條，一切要從實際出發！

搞這些是爲了什麼？

不管是主幹或是共享分支，都是一個個普通的 Git 分支，咱們爲了實現團隊協做流程以及 CI/CD 流程，纔會有各類命名分支，不用把它們想得太複雜。

要搞清楚團隊協做流程這部份內容的話，我我的以爲若是能正確理解上面提到的三個成熟的 flow ，通常就沒什麼問題，剩下的就是隨機應變的應用了。

預告

此次的分享是爲了我以後要實現的流程作鋪墊，你能夠理解爲前置技能吧，後續我經過項目分享 Github flow 和其 CI/CD 的流程。