YA！本系列文已經進入第 5 天！在艦長拖了4 天的時間之後，今天我們終於要進到 Project 了！說是這麼說，但其實今天也還不會深入 Project 啦～（揍飛）

背景說明

從今天開始，後續的文章我們會試著模擬一個開發團隊的運作，藉此了解當一個團隊打算使用 GitLab 時，會逐一遇到哪些問題，並且需要使用 GitLab 的哪些功能，所以讓我們先來說明一下故事背景，大家可以想像一下這個情境。

伴隨著公司的發展計畫，從今天開始公司將要開展一項全新的產品，為此公司籌組了一個全新的開發團隊，計畫從零開始達成這項產品開發任務。最初開發團隊將由以下的成員組成：

• Boss
• PM
• Dev Leader
• Developer
• QA

依據這樣的故事背景，現在這個團隊要在老闆的一聲令下開始運作了！

從建立 Group 和 Project 開始

首先，團隊才剛組成，為了讓團隊能順利的開展工作，擁有 GitLab 較高 User 權限的 Dev Leader 需要負責為團隊建立所需之 GitLab Group 與 Project。

第一步我們先以 Unicorn 為名，建立第一層的 Internal Group，確保本產品所有的 Project 都隸屬於此 Internal Group，限制只有公司之內的 User 才能看見此產品隸屬的 Group 與 Project。

（Group 的 Visibility Level 設定為 Internal 即代表只有能登入此 GitLab 的 User 才能看見有此 Group 存在。）

接著替這次必須保密到家的重點產品，在該 Internal Group 中分別建立了名為 NCC-1701 的 Private Project，以及名為 SDF-1 的 Internal Project。最核心的產品程式碼必須保密到家，所以為其建立的是 Private Project；而圍繞著產品可能延伸產出的 Packages 則規劃保存在 Internal Project 中，因為也許未來公司其他產品計畫也有機會使用到這些 Packages，必須讓其他團隊的人有機會找到它。

（先進入 Group，再點擊 New project 建立隸屬該 Group 的 Project。）

（在新增 Project 時，可以選擇該 Project 隸屬哪個 Group 或 User，不過一般的 User 只能建立自己的 Project，只有較高權限的 User，才會如上圖有多個選項可以選擇。如果有不想被無關者發現的 Project，務必要將 Visibility Level 設定為 Private。）

為團隊成員設定合乎職責的 Member Permissions

Group 與 Project 建立完畢後，緊接著要將團隊所有的成員加入成為 Group 的 Member，並根據職責給予不同的 Member Permissions。

• Boss 基本上只出一張嘴，為了避免他沒事亂按亂改，因此先分配為 Member Permissions 為 Guest。（老闆：桌上那個發射核彈的紅色按鈕可以按嗎？）
• Dev Leader 因為是 Group 的建立者，因此 Member Permissions 為 Owner，擁有 Group 的最高權限，可以管理 Group 旗下的 Members、Projects 及各種 Settings。
• Senior Developer 是資深的開發者，也會負責 Code Review 與 git 分支管控的工作，因此 Member Permissions 為 Maintainer。
• Developer 是一般的開發者，只要專心寫程式即可，因此 Member Permissions 為 Developer，負責 Commit Code 與送出 Merge Request 給 Senior Developer 進行 Code Review。
• Tester 是測試人員，負責程式的測試與驗收，無需提交 Commit 或發送 Merge Request，但需要能夠回報 Issue 的權限，因此 Member Permissions 設定為 Reporter。

（依據不同的職責，設置合適的 Member Permissions，做出適當的權限控管。）

一但加入成為 Group 的 Member，便會自動成為該 Group 底下所有 Project 的 Member，這功能能替我們節省許多設定 Member 的時間。

（查看 Project 的 Members 即可發現，Project 已直接繼承了 Group 的 Members，並且無法更改。）

雖然我們可以透過 Group 一次搞定自己團隊成員的 Member Permissions，但因為有些職務角色會同時支援數個開發團隊，並非專屬於自己的團隊，同時這些角色也無需加入 Group 之下的每一個 Project。針對此種角色，我們就必須直接在各個 Project 的 settings > Members 逐一將他們設定為 Member。

（例如 PM 僅需關注主要產品之 Project，因此不加入 Group，而是依據 Project 逐一設定為 Member。）

小結

今天我們將團隊接下來工作會使用之 GitLab 的 Group、Project 及 Member Permissions 大致搞定。透過完成這項前置作業，後續團隊成員才能擁有足夠的權限來使用 GitLab。雖然這都只是一些 GitLab 基本的操作，如果是一人團隊時可能不太重要（因為一人團隊大概全都開最高權限、都設定為 Private Project 即可）；但如果是多人團隊時，這些設定將與後續團隊成員的工作默契、職責歸屬、團隊開發流程與協作方式有關，可就不容小覷了。

今天的內容就先到這裡，明天我們會介紹一下 GitLab 官方提出的 GitLab Workflow，看一下其中有什麼獨到之處！我們明天見～