GitLab 專案與群組的組織與應用

在 GitLab 平台上，有效地組織和管理專案是提升團隊協作效率的關鍵。理解 GitLab 的核心元件「專案」和「群組」，以及它們之間的層級關係，能幫助開發團隊更有效地管理程式碼、追蹤問題和協作開發。每個 GitLab 專案都包含一個 Git 倉函式庫，作為程式碼的儲存中心，而多個相關的專案可以被組織到一個群組中，方便統一管理和設定許可權。群組可以包含子群組，形成多層次的組織架構，以適應不同規模和複雜度的專案。透過群組，團隊成員可以更方便地分享程式碼、追蹤問題、進行討論，並有效控制不同成員的存取許可權。此外，GitLab 的問題追蹤系統也扮演著重要的角色，它不僅可以用於追蹤錯誤和新增功能，還可以應用於技術選型研究、團隊調查、活動規劃等各種場景。透過標籤系統，團隊可以更有效地分類別和管理問題，並根據不同的標籤追蹤專案的進度和狀態。

GitLab 元件深入解析

GitLab 是一個強大的開發協作平台，其核心概念和元件是理解和有效使用它的關鍵。本文將探討 GitLab 的主要元件，特別是「專案」和「群組」，並透過具體案例來說明它們的應用。

專案與群組的組織方式

在 GitLab 中，專案是基本的建構單位。每個專案代表一個單一的軟體產品或非軟體專案。專案是存放檔案和啟動 GitLab 各種功能的起點。以下是一些典型專案的例子：

開發團隊 #1 使用的找附近洗車場所的行動應用程式
開發團隊 #2 使用的同一洗車應用程式的桌面版本
技術撰寫團隊使用的檔案
事件規劃團隊使用的即將舉辦的會議
全公司使用的新員工入職任務

這些例子顯示了專案不僅僅適用於軟體開發，也可以用來計劃、管理和追蹤任何型別的工作。雖然大多數 GitLab 專案集中在軟體開發，但企業也可以找到許多非技術性用途。

在 GitLab 中，如何將工作分割成專案沒有固定規則。例如，一家公司可能會將所有檔案放在一個獨立的專案中，而另一家公司可能會將每個軟體產品的檔案包含在該產品的專案中。最重要的是找到適合自己的結構，並且不要害怕進行實驗和調整。

GitLab 專案的詳細解析

GitLab 專案可以被視為包裹著一個 Git 倉函式庫。這個倉函式庫是倉函式庫的「金版」，包含了所有 Git 提交、標籤和分支。以下是 GitLab 專案的示意圖：

  graph TD;
    A[GitLab 專案] --> B[Git 倉函式庫];
    B --> C[Git 提交];
    B --> D[Git 標籤];
    B --> E[Git 分支];

此圖示展示了 GitLab 專案的基本結構。專案中包含了一個 Git 倉函式庫，而這個倉函式庫則包含了所有的提交、標籤和分支。

群組：組織相關專案的方式

當你有多個相關專案時，可以使用 GitLab 群組來集中管理這些專案。例如：

屬於同一團隊的專案
同一軟體不同平台（如 macOS 和 Windows）的版本
與資料函式倉管理相關的專案

群組不僅可以包含專案，還可以包含其他群組，最多可達 20 層次。這使得你可以靈活地組織你的專案。

以下是一個示例結構，幫助你理解群組、子群組和專案的關係：

  graph TD;
    A[Acme Anvils] --> B[Sales Software];
    A --> C[Internal Software];
    B --> D[iOS App];
    B --> E[Android App];
    B --> F[Web App];
    C --> G[Inventory Management];

在此圖示中，Acme Anvils 有兩個主要群組：銷售軟體和內部軟體。銷售軟體群組下有 iOS、Android 和網頁應用程式專案，而內部軟體群組下有庫存管理專案。

角色與許可權管理

群組不僅僅是收集相關專案的工具，它們還可以用來設定角色和許可權。透過群組，你可以邀請其他 GitLab 使用者成為成員，並為他們分配角色和許可權。這樣可以簡化對多個使用者的存取控制。

此外，群組還可以聚合所有子專案的元素。例如，你可以在單一頁面上檢視所有子專案的問題。

案例分析：Hats for Cats 專案

假設你有一個名為 Hats for Cats 的網路商店專案。你決定這個商店需要有三種形式：網頁應用程式、iOS 應用程式和 Android 應用程式。儘管這些產品之間有一些相似的邏輯，但由於實作差異較大，每個都需要自己的專屬專案。

由於 iOS 和 Android 均為行動平台，你決定將它們收集在一個專門負責行動開發的群組中。然後，你將這個群組與網頁應用程式專案收集在一個名為 Hats for Cats 的總群組中。最後，你決定建立一個新專案來儲存平台無關的線上檔案。

要實作這樣的結構，首先建立頂級 Hats for Cats 群組。然後在該群組中建立名為 Mobile 的子群組。接下來建立以下專案：

在 Hats for Cats 群組中建立名為 Documentation 的專案。
在 Hats for Cats 群組中建立名為 Web 的專案。
在 Mobile 子群組中建立名為 iOS 的專案。
在 Mobile 子群組中建立名為 Android 的專案。

  graph TD;
    A[Hats for Cats] --> B[Documentation];
    A --> C[Web];
    A --> D[Mobile];
    D --> E[iOS];
    D --> F[Android];

內容解密：

GitLab 專案的定義：GitLab 專案是基本的建構單位，代表單一軟體或非軟體專案。
Git儲存函式庫：每個 GitLab 專案包含一個 Git儲存函式庫，這是倉函式庫的「金版」，包含所有提交、標籤和分支。
圖示展示：圖示展示了 GitLab 專案的基本結構及其與 Git儲存函式庫之間的關係。
GitLab 群組：當有多個相關專案前時使用Gitlab Group來集中管理這些專案。
許可權管理：透過組組織許可權設定來簡化對多個使用者存取控制。
專案結構：透過建立頂級、子級以及具體專案來實作專案組織。

其他相關文章推薦：

如果對於GItlab相關功能想要更深入瞭解, 推薦以下文章:

瞭解 GitLab 構成元件

在 GitLab 中，你會發現一個結構化的群組和專案層級架構，這樣的架構能夠幫助你更好地組織和管理你的開發工作。以下是一些基本的概念和結構：

專案與群組

專案：每個專案都包含了一個 Git 儲存函式庫，你可以將程式碼儲存在這裡。專案是你在 GitLab 中進行大部分工作的中心位置。
群組：多個相關的專案可以被收集到一個群組中。群組可以包含專案、其他群組，或者兩者皆有。透過在群組和子群組中組織你的專案，你不僅可以保持它們井然有序且易於找到，還能夠在群組層級上分配許可權給其他團隊成員，並讓這些許可權應用到群組內的所有專案。

接下來，玄貓將介紹 GitLab 的另一個重要功能：問題追蹤（Issues）。

使用問題追蹤工作

在 GitLab 中，問題（Issues）是用來追蹤單一工作任務的地方。如果你曾經使用過其他工具來規劃和追蹤工作，可能會遇到類別似「故事」或「票據」的術語來描述類別似於 GitLab 問題的元件。問題存在於 GitLab 專案內部，每個問題只屬於一個專案（雖然它們可以在專案之間移動）。除了與專案相關聯外，問題還與大量其他 GitLab 元件相關聯，這些關聯是 GitLab 能夠跨越軟體開發生命週期（SDLC）各個階段的重要因素。

問題結構

GitLab 問題由幾個部分組成，以下是最重要的幾個：

標題：簡短描述問題內容。例如，「新增常見問題頁面」、「修復錯誤 #12」或「提升頁面載入效能至 20%」都是合理的問題標題。
描述：可以包含任意長度的文字，也可以包含截圖或連結，並且支援 Markdown 格式。隨著更多資訊浮現或問題方向變化，描述可以隨時編輯。
選擇性後設資料欄位：例如：
- 指派人：負責推進該問題的人員。
- 截止日期：可以直接分配給一個問題。
- 標籤：用來優先處理、路由或報告問題進度等。
- 權重：描述預期需要完成該問題所需的工作量。可以使用具體（例如人小時）或抽象（例如小任務一點、中等任務兩點、大任務三點）的指標。
討論區域：團隊成員可以進行類別似 Facebook 或 Instagram 的串接討論。

圖示

  classDiagram
    class Project {
        +String name
        +GitRepository repo
        +List<Issue> issues
    }

    class Group {
        +String name
        +List<Project> projects
        +List<Group> subgroups
    }

    class Issue {
        +String title
        +String description
        +Assignee assignee
        +Date dueDate
        +List<String> labels
        +int weight
        +boolean isOpen
        +List<Comment> discussion
    }

    class Assignee {
        +String name
    }

    class Comment {
        +String text
        +User author
    }

    Project "1" -- "*" Issue : contains
    Group "1" -- "*" Project : contains
    Group "1" -- "*" Group : contains

小段落標題

問題之間的關係

大多數專案都包含許多具有開啟和關閉狀態的問題。GitLab 提供了一種方便的方法來檢視專案中的所有問題列表，並深入瞭解任何列表中的問題。你還可以從群組層級而不是專案層級檢視問題列表。這樣的檢視顯示了屬於該群組中任何專案的所有問題。例如，如果你想知道「Hats for Cats」應用程式的 iOS 和 Android 版本還剩下多少問題需要處理，「Mobile」群組會顯示所有開啟狀態中的問題。

圖示

  graph TD;
    A[Project A] --> B[Issue 1];
    A --> C[Issue 2];
    D[Group X] --> A;
    D --> E[Project B];

小段落標題

問題追蹤例項

以下是來自「Hats for Cats」專案中的範例問題：

圖示

  graph TD;
A[Problem] --> B[Title];
A --> C[Description];
A --> D[Metadata];
A --> E[Discussion];

B --> F["Add FAQ Page"];
C --> G["Detailed description with images and links"];
D --> H["Assigned to: John Doe"];
D --> I["Due Date: Oct.10, 2024"];
D --> J["Labels: Feature Request, High Priority"];
D --> K["Weight: Medium"];
E --> L["Comments by team members"];

小段落標題

這樣的一種結構和設計讓我們能夠更有效地管理和跟蹤專案中的各種任務和工作專案，進而提升整體開發效率及協作能力。

使用 GitLab 追蹤工作與問題管理

在現代軟體開發流程中，使用問題（issues）來追蹤工作是一個常見且有效的方法。GitLab 作為一個強大的版本控制與協作平台，提供了豐富的問題管理功能，能夠應用於各種任務。以下將探討 GitLab 問題的多樣用途、標籤系統以及常見的工作流程。

GitLab 問題的多樣用途

雖然許多人認為問題主要用於軟體開發相關的任務，但實際上，GitLab 的問題管理功能可以應用於更廣泛的場景。以下是一些常見的應用範例：

新增功能：記錄並追蹤需要開發的新功能。
修復錯誤：追蹤並解決已知的軟體錯誤。
編寫自動化測試：確保新功能或修復後的穩定性。
設定資料函式庫：組態專案所需的資料函式庫環境。
組態工具：為團隊組態開發或佈署所需的工具。
技術選型研究：評估和選擇最適合專案的技術方案。
頭腦風暴：針對特定問題提出解決方案。
計劃活動：組織和管理專案相關的活動或會議。
團隊調查：針對編碼標準等問題進行團隊投票。
安全事件管理：報告和處理安全漏洞或事件。
新產品或功能建議：收集和討論新產品或功能的建議。
提出問題：讓團隊成員對某些問題進行討論和提供意見。
設計請求：請求設計師為公司活動設計 T 恤等物品。

這些範例僅是冰山一角，實際上，GitLab 的問題管理功能可以應用於技術和非技術領域，且適用於個人或整個公司。

次段落標題：迎新入職

例如，GitLab 在每位新員工入職時，都會建立一個包含歡迎文字和入職任務清單的問題。這些任務由新員工逐一完成並勾選。主管和人力資源部門會在前幾週監控這些問題，確保新員工順利完成入職流程。完成後，這些問題可以作為公司政策和流程的參考資源。

標籤系統

在深入瞭解如何使用問題之前，我們需要介紹標籤系統。標籤是彩色標記，包含簡短文字，可以應用於問題或其他 GitLab 元件（如合併請求），並在不再需要時移除。你可以根據專案或群組需求定義自己的標籤，並隨時新增或刪除。

次段落標題：常見標籤範例

以下是一些常見的標籤範例：

High Priority：表示需要立即處理的高優先順序問題。
QA：表示由品質保證團隊負責的問題。
Status::Healthy：表示按計劃進行中的健康狀態問題。
Status::At Risk：表示進度落後且需要增加資源處理的風險狀態問題。

注意到最後兩個標籤內含雙冒號（::），這是 GitLab 中特殊語法，將這些標籤變成範圍標籤（scoped labels），表示互斥性。也就是說，一個問題只能同時擁有其中一個範圍標籤，而非範圍標籤則可以任意組合使用。

問題工作流程

與許多 GitLab 元件相似，使用問題沒有一個固定的工作流程適用於所有情境。根據自身需求和團隊文化，你可以自由探索最適合自己的方法。以下是一個典型的問題工作流程範例：

識別任務：想出需要完成的工作並確定該工作屬於哪個專案。例如，「Hats for Cats」iOS 專案需要研究 Objective-C 和 Swift 語言以決定哪一個語言適合用來編寫 iOS 應用程式。
建立問題：在該專案中建立一個名為「研究 iOS 語言」的問題，並描述可能使用的語言及初步感受。
設定權重：根據預期的人天數（person-days）設定權重。例如，給這個任務設定兩天的人天數。
設定截止日期：設定任務截止日期。例如，「三天內完成」。
新增標籤：使用「iOS」和「High Priority」等標籤來優先化和分配問題。
討論問題：團隊成員討論各自對不同 iOS 語言的經驗、提問、新增外部連結及截圖等資料。
指派任務：將該問題指派給最有經驗的開發者。
更新標籤：根據工作進度更新標籤。例如，移除「High Priority」並在進度落後時新增「Status::At Risk」等範圍標籤。
關閉問題：當開發者完成研究並在討論區分享結果後關閉該問題。

安全編輯檔案：提交、分支與合併請求

在前一章中，我們學習瞭如何使用 Git 中的分支與提交來管理版本控制。GitLab 作為 Git 的封裝平台（雖然它比這更強大），同樣重視分支與提交機制。此外，GitLab 還引入了一個專屬概念——合併請求（Merge Request, MR）。以下將介紹如何使用這三個元件在 GitLab 中進行檔案編輯：

建立分支：在開始編輯之前，需要先建立分支。你可以使用 git branch <BRANCH-NAME> 命令建立本地分支，然後使用 git push 命令推播到遠端倉函式庫。或者直接在 GitLab GUI 中建立新分支並同步到本地倉函式庫。
提交變更（Commits）：在分支中進行檔案編輯後，提交變更到本地倉函式庫。提交是檔案快照（snapshot），包含了對一個或多個檔案所做的修改。
建立合併請求（MR）：在完成變更並推播到遠端倉函式庫後，建立合併請求以請求將該分支合併到主分支（通常是 main 或 master）。這樣其他成員可以檢閱程式碼並進行討論、測試等操作。

內容解密：

此段落詳細介紹瞭如何在 GitLab 中安全地編輯檔案：首先要建立分支來進行獨立開發；然後在分支中進行必要修改並提交；最後透過合併請求將分支上的變更合併到主分支中去。 GitLab 提供了靈活性高且強大工具支援所有以上操作模式：

透過終端命令列進行操作：
- git branch <BRANCH-NAME> 建立新分支
- git push 推播分支到遠端倉函式庫
透過 GitLab GUI 進行操作：
- 直接在 GitLab 介面建立新分支
- 使用 git fetch 和 git pull 命令同步本地與遠端倉函式庫
使用合併請求（Merge Request）：
- 在完成變更並推播到遠端倉函式庫後建立 MR
- 請求其他成員檢閱、討論及測試程式碼

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。