Gitlab上手指南（二）｜大多數企業為什麼會使用Gitlab，Gitlab工作流是什麼樣的？

語言: CN / TW / HK
時間 2023-03-11 23:15:31

是什麼

官方話術：

GitLab是由GitLabInc.開發，使用MIT許可證的基於網絡的Git倉庫管理工具，且具有wiki和issue跟蹤功能。使用Git作為代碼管理工具，並在此基礎上搭建起來的web服務。

GitLab由烏克蘭程序員DmitriyZaporozhets和ValerySizov開發，它使用Ruby語言寫成。後來，一些部分用Go語言重寫。截止2018年5月，該公司約有290名團隊成員，以及2000多名開源貢獻者。GitLab被IBM，Sony，JülichResearchCenter，NASA，Alibaba，Invincea，O’ReillyMedia，Leibniz-Rechenzentrum(LRZ)，CERN，SpaceX等組織使用。

GitLab擁有與Github類似的功能，能夠瀏覽源代碼，管理缺陷和註釋。可以管理團隊對倉庫的訪問，它非常易於瀏覽提交過的版本並提供一個文件歷史庫。團隊成員可以利用內置的簡單聊天程序(Wall)進行交流。它還提供一個代碼片段收集功能可以輕鬆實現代碼複用。

為什麼

為什麼企業都是用gitlab，而不是github和gitee等呢？

當一個項目版本多了，開發人員多了，單純的git管理還是很多問題，一方面是開發人員權限過大，二是運維人員不太瞭解我們開發上面的流程，於是想着用更好的工具來管理項目。於是想到gitlab。

CI/CD

這裏的CI/CD其實指的是持續集成（CI）和持續交付、持續部署（CD），CI就是軟件工程師每天頻繁地將更新代碼的副本傳遞到共享位置的過程。所有的開發工作都在預定的時間或事件中進行集成，然後自動測試和構建工作。通過CI，開發過程中出現的錯誤能被及時發現，這樣不僅加速了整個開發週期，而且使軟件工程師的工作效率更高。而CD 表示持續交付（CD）是創建高質量應用程序的第二個難題。CD是一門軟件開發學科，利用技術和工具快速地交付生產階段的代碼。由於大部分交付週期都是自動化的，所以這些交付能夠快速地完成。

後文我們會詳細介紹CI/CD的工作流程

權限控制和協同

在一個 GitLab 項目上一起工作的最簡單方法就是賦予協作者對 git 版本庫的直接 push 權限。 你可以通過項目設定的 “Members（成員）” 部分向一個項目添加寫作者，並且將這個新的協作者與一個訪問級別關聯（。 通過賦予一個協作者 “Developer（開發者）” 或者更高的訪問級別，這個用户就可以毫無約束地直接向版本庫或者向分支進行提交。

另外一個讓合作更解耦的方法就是使用合併請求。 它的優點在於讓任何能夠看到這個項目的協作者在被管控的情況下對這個項目作出貢獻。 可以直接訪問的協作者能夠簡單的創建一個分支，向這個分支進行提交，也可以開啟一個向 master 或者其他任何一個分支的合併請求。 對版本庫沒有推送權限的協作者則可以 “fork” 這個版本庫，向 那個 副本進行提交，然後從那個副本開啟一個到主項目的合併請求。 這個模型使得項目擁有者完全控制着向版本庫的提交，以及什麼時候允許加入陌生協作者的貢獻。（這有點類似 github，但目前github私有庫收費）

在 GitLab 中合併請求和問題是一個長久討論的主要部分。 每一個合併請求都允許在提出改變的行進行討論（它支持一個輕量級的代碼審查），也允許對一個總體性話題進行討論。 兩者都可以被分配給用户，或者組織到 milestones（里程碑） 界面。

這個部分主要聚焦於在 GitLab 中與 Git 相關的特性，但是 GitLab 作為一個成熟的系統，它提供了許多其他產品來幫助你協同工作，例如項目 wiki 與系統維護工具。 GitLab 的一個優點在於，服務器設置和運行以後，你將很少需要調整配置文件或通過 SSH 連接服務器；絕大多數的管理和日常使用都可以在瀏覽器界面中完成。

Git Flow 工作流介紹

一個企業當中項目，一般來説，是幾個人同時進行開發的，那麼如何對git分支進行管理就成了一個重點問題。

那麼這裏，我們就需要介紹一下我們的git flow工作流程了。

我們先從代碼的運行環境來説起。代碼運⾏的環境 ⼀般來説，公司團隊都會有⾄少這⼏個環境：

  • 本地開發環境： 開發⼈員⾃測的，可以是⾃⼰本地部署的靜態服務器，當然也可類似是運⾏ npm server類似的環境，本地環境運⾏ 的代碼可以是任何分⽀的
  • dev開發環境： 這個環境是⽤開發分⽀dev產出的代碼來部署的，唯⼀的公⽤的
  • 測試&預發佈環境： 這個環境是⽤開發分⽀release產出的代碼來部署的，唯⼀的公⽤的
  • 線上⽣產環境： 這個環境是⽤開發分⽀master產出的代碼來部署的，唯⼀的公⽤的

對應的git分支模型是這樣的

對應的分支策略是這樣的

  • master ：保護分⽀，對應的就是⽣產環境的分⽀
  • release：保護分⽀，所有開發完成的分⽀會申請合併到release分⽀，提供給測試⼈員測試
  • feature-*：功能分⽀，具體功能開發
  • dev/test-*：開發分⽀&髒分⽀，對應的是⼤家共⽤的開發環境，上⾯的代碼會部署到⼀個公共的開發環境，供開發⼈ 員做⾃測，應付⼀些⽇常、⾮⽇常的調試
  • hotfix-*：bug緊急修復分⽀，可以直接合併到master，（假如release合併了⼏個feature分⽀，正在測試的情況 下，發現需要緊急修復的buf，緊急修復測試完畢後，可以直接合併到master，如果合併到release，在由 release合併到master，那些正在測試的功能或者還不準備上線的功能就會跟着直接上線了）

工作流程介紹

  1. 接到需求⽂檔，做評審後分配個每個⼈或⼩組的功能開發，相關⼈員從master 檢出功能分⽀
  2. 開發的時候除了會在本地測試，有需要還會合併到dev分⽀，在公共的開發環境去⾃⼰做測試
  3. 因為在開發功能的期間，可能有hotfix完成合併到master，合併代碼的時候習慣merge⼀下master，防⽌衝突 等
  4. ⾃測完成之後，申請合併到release，合併成功後部署到測試環境後通知測試⼈員做測試
  5. 測試通過後，release申請合併到master，準備上線
  6. 如果測試不通過，在功能分⽀修改後重新merge
  7. 上線成功穩定後刪除對應的功能分⽀，dev 合併最新的master分⽀
「」
「」