GitLab 不僅僅是一個程式碼儲存函式庫，它更是一個功能豐富的 DevOps 平台。其中，Issues 和合併請求（Merge Requests）是兩個核心功能，有效運用這兩個功能能大幅提升團隊協作效率和程式碼品質。本文將探討如何利用 GitLab Issues 追蹤工作、管理專案，以及如何使用合併請求進行程式碼審查和版本控制。首先，Issues 不僅能追蹤 bug 和新功能開發，還能用於技術研究、團隊討論、甚至規劃活動等各種工作。透過標籤系統，可以有效分類別和管理 Issues，例如設定優先順序、指派負責人、追蹤進度等。在 GitLab 中，每個 Issue 都可以有獨立的討論串，方便團隊成員溝通和交流。接著，合併請求是確保程式碼品質的關鍵步驟。在提交程式碼變更後，建立合併請求可以讓團隊成員進行程式碼審查，並透過討論和建議提升程式碼品質。GitLab 的合併請求功能也支援 CI/CD 整合，可以在合併程式碼前自動執行測試和掃描，確保程式碼的穩定性和安全性。此外，設定批准規則可以更嚴謹地控管程式碼合併流程，例如要求資深工程師或團隊負責人批准後才能合併程式碼。總之，善用 GitLab Issues 和合併請求，能幫助團隊更有效地追蹤工作、管理專案，並提升程式碼品質，實作更順暢的軟體開發流程。
討論區
- @janedoe: 我覺得這是一個很棒的想法！
- @johndoe: 謝謝！我會盡快完成這項任務。
### 檢視與管理問題
GitLab 提供了多種方法來檢視和管理問題：
1. **專案層級**：你可以檢視一個專案中的所有問題。
2. **群組層級**：你也可以檢視一個群組內所有專案中的所有問題。
例如，如果你想知道「Hats for Cats」應用程式的 iOS 和 Android 版本還有多少未完成的問題，你可以在 Mobile 群組層級檢視所有未解決的問題。
透過這樣的結構和功能，GitLab 不僅能夠有效地追蹤和管理工作進度，還能夠協助團隊成員更好地合作和溝通。
## 使用 GitLab Issues 跟蹤工作
在 GitLab 中，issues 並不僅僅用於追蹤軟體開發相關的工作，它們可以涵蓋廣泛的任務型別。讓我們來看看 issues 可以用來描述和跟蹤的各種任務：
1. **新增功能**：開發一個新的產品功能。
2. **修復錯誤**：解決已知的程式碼漏洞。
3. **編寫自動化測試**：確保新功能或修復的穩定性。
4. **設定資料函式庫**：組態新的資料函式庫結構或連線。
5. **組態工具**：為團隊設定統一的開發工具。
6. **技術研究**：評估不同的技術選項。
7. **頭腦風暴**：為問題提出創新解決方案。
8. **計劃活動**：安排公司內部或外部活動。
9. **團隊調查**：收集團隊成員對編碼標準的意見。
10. **安全事件管理**：報告和處理安全漏洞。
11. **提議新產品或功能**：提出創新的產品或功能建議。
12. **問題討論**：邀請團隊成員對某個問題提出意見。
13. **設計請求**：為公司活動設計 T 恤等物品。
這些只是一些例子，issues 的應用範圍非常廣泛，可以用於技術和非技術工作，也可以由個人或整個公司使用。
### 權貓分享
在 GitLab，每位新員工都會被分配一個 welcome issue，包含歡迎詞和一系列入職任務。這些任務會由員工的主管和人力資源部門在員工前幾週內進行監控，確保他們順利完成入職流程。完成後，這些 issue 可以作為公司政策和程式的參考資源。
## 標籤系統
在深入瞭解如何使用 issues 之前，我們需要介紹標籤系統。標籤是帶有顏色且包含簡短文字的標記，可以應用於 issues 或其他 GitLab 元件，如 merge requests。你可以根據專案或群組的需求定義標籤，並隨時新增或刪除標籤。
### 常見標籤示例
- **高優先順序（High Priority）**：表示需要立即處理的問題。
- **QA（品質保證）**：表示品質保證團隊負責的問題。
- **狀態：健康（Status::Healthy）**：表示問題按計劃進行。
- **狀態：風險（Status::At Risk）**：表示問題進度落後，需要增加資源。
注意到最後兩個標籤中包含雙冒號（::），這表示它們是範圍內互斥的標籤。即一個問題只能同時擁有一個「狀態」標籤。
### 權貓分享
GitLab 本身也使用大量 issues 來優先排序、分配責任和跟蹤工作進度。因此，不要害怕建立和使用你需要的任何 issues，它們是免費且易於管理的。
## Issues 工作流程
GitLab 中沒有一種單一的 issues 工作流程適用於所有情況。你應該根據自己的需求和團隊文化來探索最佳實踐。以下是一個典型的 issues 工作流程範例：
1. **識別工作內容**：確定需要完成哪些工作及其所屬專案。例如，在 Hats for Cats iOS 專案中，你需要研究 Objective-C 和 Swift 語言來決定哪一種語言適合開發 iOS 應用。
2. **建立 Issue**：在相關專案中建立一個 issue 並描述工作內容。例如，「Research languages for iOS」，並附上可能語言及初步選擇建議。
3. **設定權重**：根據預期的人天數給予 issue 一個權重值，例如「2」。
4. **設定截止日期**：設定 issue 的截止日期，例如「3 天」。
5. **分配標籤**：使用標籤來優先排序和分配 issue。例如，「iOS」和「高優先順序」標籤。
6. **討論 Issue**：團隊成員分享他們對不同 iOS 語言的經驗並討論相關部落格文章。
7. **分配 Issue**：將 Issue 分配給最有經驗的人員處理。
8. **更新標籤**：隨著工作進展更新標籤。例如，移除「高優先順序」並新增「狀態：風險」。
9. **關閉 Issue**：當工作完成後關閉 Issue。
### 權貓分享
Issue 是 GitLab 中非常重要的一部分。學會如何建立、檢視和編輯 issue 是成為有效 GitLab 使用者的關鍵。透過實踐來熟悉 issue 的操作是非常有必要的。
## 安全地編輯檔案：提交、分支和合併請求
在上一章中我們學習瞭如何在 Git 中使用分支和提交。因為 GitLab 根據 Git 儲存函式庫（儘管它做得更多），分支和提交也是使用 GitLab 的重要部分。此外還有一個相關概念—合併請求（Merge Request, MR），這是專屬於 GitLab 的概念。接下來我們將介紹 MR 以及如何在 GitLab 中使用這三者。
### 權貓分享
GitLab 通常提供多種方式來完成同一件事。例如，你可以透過終端機輸入命令或使用 GitLab GUI 來操作分支和提交。然而 MR 則需要使用 GitLab GUI 來進行操作。
### 建立分支
在提交編輯到分支之前，你需要先建立該分支。回想一下上一章所學內容：
1. 在終端機中使用 `git branch <BRANCH-NAME>` 命令建立分支
2. 接著使用 `git push` 命令將該分支推播到遠端倉函式庫
或者你也可以透過以下方式操作：
1. 在 GitLab 中直接建立新分支
2. 然後透過 `git fetch` 和 `git pull` 命令將該分支提取到本地倉函式庫（假設你有本地倉函式庫）
### 內容解密：
#### 分支與提交
**分支 (Branch)**：在開發過程中，分支允許開發者在不同版本之間切換而不會影響主執行緒式碼。每個新功能或修復都應該從主執行緒式碼中建立一個新的分支進行開發。
**提交 (Commit)**：每次修改程式碼後都應該進行一次提交，這樣可以記錄每次修改並且其他開發者分享。
#### 分支與提交示例：
假設我們正在開發 Hats for Cats iOS 應用中的一個新功能—新增搜尋功能：
```shell
# 建立名為 feature/search 的分支
git branch feature/search
# 推播到遠端倉函式庫
git push origin feature/search
傳統命令列與GUI操作對比：
傳統命令列操作適合那些對控制檯操作熟悉的人群，因為它提供了更多靈活性與控制許可權；而 GUI 操作則適合對控制檯不熟悉的人群或希望簡化流程的人群。
使用 GitLab 的核心功能
玄貓在此介紹如何在 GitLab 中進行基礎操作，包括建立分支、提交變更以及合併請求（Merge Request）。這些操作是有效利用 GitLab 的關鍵，即使你對 Git 相關指令已經有一定了解，瞭解這些基本操作仍然非常重要。
建立分支
分支是 Git 儲存函式庫的一部分，而 GitLab 專案其實就是一個 Git 儲存函式庫加上許多額外功能。因此，在 GitLab 專案中建立分支是非常直觀的。假設你要為「Hats for Cats」Android 應用程式新增一個允許變更密碼的功能分支，以下是具體步驟：
- 瀏覽至你的群組結構並開啟 Android 專案。
- 在左側導覽列中，點選「Repository > Branches」。這會顯示該專案儲存函式庫中的所有分支。
- 點選「New branch」按鈕，填寫分支名稱後點選「Create branch」，就完成了。
編輯檔案並提交變更
建立分支後，你可以開始對其進行修改並提交變更。在 GitLab 中有兩種方式來完成這項操作：終端機指令或是使用 GitLab 的圖形介面。
使用終端機進行提交
如果你熟悉終端機指令，可以使用以下三步驟：
git add <FILE-NAME>：將檔案新增到暫存區。git commit --message "<MESSAGE>"：提交變更並附上訊息。git push：將變更推播到遠端儲存函式庫。
使用 GitLab 的圖形介面進行提交
如果你更喜歡在網頁上操作，可以按以下步驟進行：
- 從左側導覽列中點選「Repository > Files」進入專案儲存函式庫。
- 確保你正在編輯的分支正確，從頁面左上角的分支下拉選單中選擇。
- 在檔案列表中點選你想要編輯的檔案名稱，這會顯示其內容。
- 點選「Edit in Web IDE」開啟內建編輯器進行修改。
- 編輯完畢後，點選「Commit…」，輸入提交訊息。如果還沒有為此分支建立合併請求，建議勾選「Start a new merge request」。
- 點選「Commit」完成提交。
如果你已經將儲存函式庫克隆到本地機器上，可能會想要使用 git checkout <BRANCH-NAME> 和 git pull 指令將變更同步到本地儲存函式庫。不過，這通常不需要在每次提交後都執行。
轉換分支
在 GitLab 中轉換分支非常簡單。從命令列可以使用 git checkout <BRANCH-NAME> 或 git switch <BRANCH-NAME>。同樣地，在圖形介面中也可以透過頁面左上角的分支下拉選單來切換分支。
提交記錄
檢視某個分支的提交記錄是 Git 儲存函式庫中的常見操作之一。在命令列中可以使用 git log 指令來檢視反向時間順序的提交記錄，包含作者、時間戳記、SHA 以及提交訊息等資訊。
在 GitLab 的圖形介面中也可以檢視這些資訊：
- 進入專案的主要頁面。
- 從分支下拉選單中選擇你感興趣的分支。
- 點選「History」按鈕即可檢視該分支的提交記錄。
GitLab 的圖形介面還提供了更友好的顯示方式：每個提交都可以點選檢視每個檔案的變更情況，並以易於閱讀的並排格式顯示（也可以切換成內嵌格式）。
合併請求（Merge Request）
合併請求（Merge Request）是 GitLab 中一個非常重要且常用的功能。它允許你請求將一個分支合併到另一個分支。合併請求類別似於問題（Issue），包含標題、描述、指派人以及線性討論等欄位。
以下是如何在 GitLab 中建立一個合併請求：
- 在專案頁面中點選「Merge Requests」。
- 點選「New merge request」。
- 填寫來源和目標分支，然後點選「Compare branches and continue」。
- 填寫標題和描述後點選「Submit merge request」。
認識 GitLab 的合併請求與程式碼審查
在軟體開發的過程中，編輯檔案並安全地進行版本控制是至關重要的。GitLab 提供了強大的合併請求（Merge Requests, MRs）功能，讓開發者能夠安全且有條理地將程式碼合併到主要分支。合併請求不僅僅是簡單的程式碼合併工具，它還提供了許多附加功能，讓開發者能夠更好地管理和審查程式碼。
合併請求的基本概念
合併請求的核心概念是在源分支（source branch）與目標分支（target branch）之間進行操作。源分支包含了新的提交（commits），而目標分支則是你希望將這些新提交合併進去的分支。例如，如果你想要將 branch-a 合併到 main 分支，那麼 branch-a 就是源分支，而 main 就是目標分支。
合併請求會顯示源分支上的所有 Git 提交，並將每個提交中的修改集中在一個畫面中。這樣可以讓你清楚地看到將源分支合併到目標分支後會對檔案產生什麼影響。
自動化測試與掃描
合併請求還包含了一個特別的面板，顯示 CI/CD 傳送帶對該分支程式碼執行的自動化測試和掃描結果。這個面板可以快速告訴你你所開發的程式碼是否正常執行、是否有安全漏洞、以及是否引入了不接受的軟體授權。這是一個非常方便的功能，因為它讓你可以快速判斷你在該分支上所做的工作是否改善了整體軟體產品。
合併按鈕
合併請求還包含一個大而明顯的「Merge」按鈕。這個按鈕的存在使得你可以輕鬆地完成合併操作。然而，這個按鈕可能會因為多種原因而被停用，無法進行合併。以下是一些常見的停用原因：
- 合併請求標題以「Draft」開頭，表示該分支仍在進行中。
- GitLab 的授權掃描器檢測到新引入的依賴項與專案的整體授權不相容。
- 分支上最近的提交自動化測試失敗。
- 一個或多個討論執行緒未解決。
- 尚未收到足夠的批准或來自適當人員的批准以滿足批准規則。
程式碼審查與批准
由於合併請求可以改變目標分支中的檔案，而目標分支通常是 main 或 master 分支（即穩定且可用於生產環境的程式碼），因此對每個 MR 的審查和批准都是至關重要的。GitLab 提供了以下幾種功能來幫助團隊進行程式碼審查：
- 您可以將評論直接連結到檔案中的一行或多行，使得建議或讚美特定程式碼變得更加明確。
- 您可以在討論區域中提出替代程式碼建議，這些建議甚至包括一個按鈕，允許原作者透過單擊 GUI 接受建議。
- 您可以指派團隊成員來審查您的編輯內容。這些審查者會收到通知，說明您希望他們審查您在合併請求中的編輯內容。
- 團隊成員可以批准您的程式碼。這與審查不同；審查通常是一個重複過程，而批准則是一次性「點贊」，表示批准者認為您的編輯已準備好合併。
您還可以建立規則來決定誰必須批准您的 MR 才能進行合併。這些規則可以變得非常複雜，涉及多個團隊成員。例如：
- 規則 1：技術負責人或架構師
- 規則 2：開發團隊經理
- 規則 3：品質保證團隊中的任何一人、安全團隊中的兩人以及架構師中的兩人
在提交之前建立合併請求
有一點可能聽起來有些奇怪：玄貓建議在建立分支後立即建立合併請求，即使還沒有提交任何程式碼到該分支。這與 GitHub 的提取請求（Pull Requests）不同，GitHub 的 PRs 單純用來提交完整的修改過後才提出。
玄貓建議在建立分支後立即建立 MR 的原因在於你可以更早地開始審查流程，並且可以更早地發現潛在問題。這樣做雖然看起來有些反直覺，但實際上有助於提高開發效率和程式碼品質。
總結來說，GitLab 的 MR 是一個強大且靈活的工具，能夠幫助開發者更好地管理和審查程式碼。透過使用 MRs、自動化測試和批准規則，開發者可以確保他們所做出的修改能夠安全且高效地整合到主分支中。
