為什么企業都用gitlab？工作流是什么樣的？

為什么企業都是用gitlab，而不是github和gitee等呢？下面本篇文章就來介紹一下原因，并聊聊gitlab工作流，希望對大家有所幫助！

是什么

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

GitLab由烏克蘭程序員DmitriyZaporozhets和ValerySizov開發，它使用Ruby語言寫成。后來，一些部分用Ruby語言重寫。截止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，那些正在測試的功能或者還不準備上線的功能就會跟著直接上線了）

工作流程介紹

• 接到需求?檔，做評審后分配個每個?或?組的功能開發，相關?員從master 檢出功能分?

• 開發的時候除了會在本地測試，有需要還會合并到dev分?，在公共的開發環境去??做測試

• 因為在開發功能的期間，可能有hotfix完成合并到master，合并代碼的時候習慣merge?下master，防?沖突 等

• ?測完成之后，申請合并到release，合并成功后部署到測試環境后通知測試?員做測試

• 測試通過后，release申請合并到master，準備上線

• 如果測試不通過，在功能分?修改后重新merge

• 上線成功穩定后刪除對應的功能分?，dev 合并最新的master分?

（學習視頻分享：Ruby語言）