為什麼企業都是用gitlab，而不是github和gitee等呢？以下這篇文章就來介紹一下原因，聊聊Gitlab工作流程，希望對大家有幫助！
是什麼
#官方話術：
GitLab是由GitLabInc.開發，使用MIT許可證的基於網路的Git##倉庫管理工具，且具有wiki和issue追蹤功能。使用Git作為程式碼管理工具，並在此基礎上建置起來的web服務。
GitLab由烏克蘭程式設計師DmitriyZaporozhets和ValerySizov開發，它使用Ruby語言寫成。後來，有些部分用Go語言重寫。截止2018年5月，該公司約有290名團隊成員，以及2,000多位開源貢獻者。 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分⽀
（學習影片分享：程式設計基礎影片）
#
以上是為什麼企業都用gitlab？工作流程是什麼樣的？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
