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

是什么

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

(相關資料圖)

GitLab擁有與Github類似的功能，能夠瀏覽源代碼，管理缺陷和注釋?？梢怨芾韴F隊對倉庫的訪問，它非常易于瀏覽提交過的版本并提供一個文件歷史庫。團隊成員可以利用內(nèi)置的簡單聊天程序(Wall)進行交流。它還提供一個代碼片段收集功能可以輕松實現(xiàn)代碼復用。

為什么

為什么企業(yè)都是用gitlab，而不是github和gitee等呢？

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

CI/CD

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

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

權限控制和協(xié)同

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

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

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

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

Git Flow 工作流介紹

一個企業(yè)當中項目，一般來說，是幾個人同時進行開發(fā)的，那么如何對git分支進行管理就成了一個重點問題。

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

我們先從代碼的運行環(huán)境來說起。代碼運?的環(huán)境 ?般來說，公司團隊都會有?少這?個環(huán)境：

本地開發(fā)環(huán)境： 開發(fā)?員?測的，可以是??本地部署的靜態(tài)服務器，當然也可類似是運? npm server類似的環(huán)境，本地環(huán)境運? 的代碼可以是任何分?的dev開發(fā)環(huán)境： 這個環(huán)境是?開發(fā)分?dev產(chǎn)出的代碼來部署的，唯?的公?的測試&預發(fā)布環(huán)境： 這個環(huán)境是?開發(fā)分?release產(chǎn)出的代碼來部署的，唯?的公?的線上?產(chǎn)環(huán)境： 這個環(huán)境是?開發(fā)分?master產(chǎn)出的代碼來部署的，唯?的公?的

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

對應的分支策略是這樣的

master ：保護分?，對應的就是?產(chǎn)環(huán)境的分?release：保護分?，所有開發(fā)完成的分?會申請合并到release分?，提供給測試?員測試feature-*：功能分?，具體功能開發(fā)dev/test-*：開發(fā)分?&臟分?，對應的是?家共?的開發(fā)環(huán)境，上?的代碼會部署到?個公共的開發(fā)環(huán)境，供開發(fā)? 員做?測，應付?些?常、??常的調(diào)試hotfix-*：bug緊急修復分?，可以直接合并到master，（假如release合并了?個feature分?，正在測試的情況 下，發(fā)現(xiàn)需要緊急修復的buf，緊急修復測試完畢后，可以直接合并到master，如果合并到release，在由 release合并到master，那些正在測試的功能或者還不準備上線的功能就會跟著直接上線了）

工作流程介紹

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

開發(fā)的時候除了會在本地測試，有需要還會合并到dev分?，在公共的開發(fā)環(huán)境去??做測試

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

?測完成之后，申請合并到release，合并成功后部署到測試環(huán)境后通知測試?員做測試

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

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

上線成功穩(wěn)定后刪除對應的功能分?，dev 合并最新的master分?

（學習視頻分享：編程基礎視頻）

以上就是為什么企業(yè)都用gitlab？工作流是什么樣的？的詳細內(nèi)容，更多請關注php中文網(wǎng)其它相關文章！

關鍵詞：