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

– 14 分鐘閱讀

在軟體開發流程中，版本控制扮演著至關重要的角色。GitLab 作為一個功能強大的版本控制平台，提供了一系列工具來管理程式碼的變更和協作。本文將探討 GitLab 的三個核心功能：提交、分支和合併請求，並闡述如何利用這些功能安全地編輯檔案、促進團隊協作，並最終提升軟體開發效率。提交記錄了每一次程式碼的變更，分支允許多個開發者同時進行不同的功能開發，而合併請求則提供了一個平台，讓團隊成員可以審查程式碼、討論修改，並最終將變更合併到主分支。透過妥善運用這些功能，開發團隊可以有效地追蹤程式碼的演進、管理不同版本的程式碼，並確保程式碼的品質和一致性。理解這些核心概念對於任何使用 GitLab 的開發者來說都至關重要。

GitLab 的基本操作及探討

GitLab 是一個強大的版本控制和協作工具，提供了豐富的功能來管理軟體開發過程。本文將探討 GitLab 的基本操作，包括如何建立分支、提交更改、檢視提交歷史以及合併請求的流程。這些操作對於有效地使用 GitLab 至關重要。

建立分支

分支是 Git 倉函式庫的一部分，而 GitLab 專案則是一個具有豐富功能的 Git 倉函式庫。建立分支可以幫助開發者在不影響主分支的情況下進行開發和測試。以下是建立分支的步驟：

  1. 導航到你的專案結構並開啟 Android 專案。
  2. 在左側導航面板中，點選「Repository > Branches」，這將顯示專案倉函式庫中現有的所有分支。
  3. 點選「New branch」按鈕，填寫分支名稱，然後點選「Create branch」按鈕完成。

假設你想為 Hats for Cats Android 應用程式新增一個允許使用者更改密碼的功能，你可以建立一個名為 allow-password-change 的分支。這樣，開發者可以在這個分支上進行相關的開發工作。

提交更改

在建立分支後，你可以對其進行編輯和提交。以下是使用 GitLab GUI 提交更改的步驟：

  1. 導航到專案的倉函式庫，點選「Repository > Files」。
  2. 確保你在正確的分支上工作，點選頁面頂部左側的分支名稱下拉選單。
  3. 在倉函式庫檔案列表中，點選你想要編輯的檔名稱。
  4. 點選「Edit in Web IDE」開啟內嵌編輯器，進行必要的更改。
  5. 如果你需要在同一次提交中編輯更多檔案，點選左側檔案瀏覽器中的下一個檔名稱，進行必要的編輯。
  6. 編輯完成後，點選「Commit…」，輸入提交資訊。如果尚未為該分支建立合併請求，建議勾選「Start a new merge request」選項。然後點選「Commit」完成提交。

使用 GitLab GUI 提交更改是一個非常方便且高效的過程，能夠讓開發者在不使用終端機的情況下直接編輯和提交程式碼。

檢視提交歷史

檢視提交歷史是理解專案的開發進度和變更情況的一個重要步驟。在 GitLab GUI 中，你可以透過以下方式檢視提交歷史：

  1. 導航到專案的首頁面。
  2. 從分支下拉選單中選擇你感興趣的分支。
  3. 點選「History」按鈕。

這將顯示該分支上的提交列表，包括每次提交的作者、時間戳、SHA 和提交資訊。相比於終端機中的 git log 命令，GitLab GUI 提供了更直觀和易於閱讀的方式來檢視提交歷史。

合併請求

合併請求（Merge Request, MR）是 GitLab 中的一個重要功能，它允許開發者請求將一個分支合併到另一個分支中。合併請求類別似於問題（Issue），包含標題、描述、分配人和討論執行緒等欄位。以下是建立合併請求的步驟：

  1. 在 GitLab 中導航到你想要合併的目標分支。
  2. 點選「Merge Requests」按鈕。
  3. 點選「New merge request」按鈕。
  4. 填寫合併請求的標題和描述，然後點選「Submit merge request」。

合併請求需要經過審核和批准才能完成合併。這一過程確保了程式碼品質和團隊協作效率。

內容解密：
  • GitLab Project：GitLab 專案是一個包含所有開發資源和程式碼倉函式庫的地方。
  • Create Branch：建立新分支以便在不影響主執行緒式碼的情況下進行開發工作。
  • Edit Files：在 Web IDE 中編輯檔案內容。
  • Commit Changes：將編輯後的檔案內容提交到當前分支中。
  • View Commit History：檢視特定分支上的所有提交記錄以瞭解程式碼變化歷史。
  • Create Merge Request：提出將一個分支合併到另一個分支的請求以進行程式碼稽核和批准。
  • Review and Approve：由團隊成員對合並請求進行稽核並批准或提出修改意見。
  • Merge Branch：在透過稽核後將源分支合併到目標分支中。

使用分支與合併請求進行安全的檔案編輯

在使用 GitLab 進行開發時，合併請求（Merge Requests，簡稱 MR）是一個強大的功能，它不僅讓你能夠安全地編輯檔案，還能夠促進團隊協作。然而，與問題（Issues）不同，合併請求包含了一些額外的欄位和功能，這些功能使得它在協作和程式碼品質管理方面更為強大。

合併請求的關鍵欄位

合併請求中有兩個關鍵欄位：來源分支（Source Branch）和目標分支（Target Branch）。來源分支是包含你新增提交的分支，而目標分支則是你希望將這些新提交合併到的分支。例如，如果你想將 branch-a 合併到 main 分支，那麼來源分支就是 branch-a，目標分支就是 main。

合併請求的顯示內容

合併請求會顯示來源分支上的所有 Git 提交，並將每個提交中的編輯整合到一個畫面中。這樣你就可以清楚地看到將來源分支合併到目標分支後會對檔案造成什麼影響。

自動化測試與掃描結果

與問題不同，合併請求還包含一個特殊的面板，顯示 CI/CD Pipeline對該分支程式碼進行的自動化測試和掃描結果。這個面板可以幫助你快速瞭解程式碼是否符合預期、是否存在安全漏洞或是否引入了不受歡迎的軟體授權。這是一個非常方便的功能，因為它讓你可以在合併之前就知道你的工作是否會改善或惡化整體軟體產品。

合併按鈕

最後，合併請求中還有一個顯眼的「合併」按鈕。這個按鈕的使命是將一個分支的提交合併到另一個分支中。然而，這個按鈕可能會因為以下原因而灰色且無法點選：

  • 合併請求標題以「Draft」開頭，表示該分支仍在開發中。
  • GitLab 的授權掃描器檢測到引入了不相容的依賴項。
  • 自動化測試失敗。
  • 一些討論執行緒未解決。
  • 未獲得足夠的批准。

這些阻擋行為都是可組態的，你可以根據團隊需求進行調整。

程式碼審查與批准

由於合併請求可以改變目標分支中的檔案，而目標分支通常是主要、主或穩定的生產準備好的分支，因此每個 MR 的審查都是至關重要的。GitLab 提供了多種功能來促程式式碼審查：

  • 你可以將評論直接連結到一行或多行程式碼上，使得建議或讚美更加具體。
  • 在討論區域中提出替代程式碼建議。
  • 指派審查者並透過電子郵件通知他們。
  • 小組成員可以批准你的程式碼。審查和批准是不同的概念；批准是一次性的一致同意。

提前建立合併請求

建立合併請求有多種方式，包括一些 GitLab 提供的捷徑。我們建議在建立新分支後立即建立一個合併請求，即使這時還沒有任何提交。這樣做可能聽起來有些反直覺，但在實際操作中，這樣可以幫助團隊更早地瞭解你正在進行的工作並提供反饋。

建議步驟

  1. 建立新分支後立即建立一個空白的 MR。
  2. 在開始編寫程式碼之前進行初步討論和規劃。
  3. 隨著開發進展不斷更新 MR 的狀態和內容。

安全編輯檔案時使用的是哪些機制？(特定答案)

  • 分支
  • 合併請求
  • 程式碼審查

使用合併請求（Merge Request）作為程式碼管理儀錶板

在 GitLab 的使用者中，合併請求（Merge Request, MR）早期在工作流程中建立的最佳實踐已經被廣泛接受。其原因有二：首先，MR 應該被視為一個「儀錶板」，它能讓你瞭解新增到分支中的程式碼整體品質。這個儀錶板可以回答以下問題：

  • 自動化測試是否透過？
  • 你的程式碼是否符合效能需求？
  • 你的程式碼是否引入了任何安全漏洞？
  • 若新增任何第三方依賴，它們的授權是否與整個專案的授權相容？
  • 你的程式碼是否符合風格和品質需求？
  • 若將應用程式作為 Docker 映像分發，是否有任何已知的安全漏洞存在於你的程式碼所封裝的基礎 Docker 映像中？

這些結果在 GitLab GUI 的其他部分也是可見的，但將它們集中呈現在 MR 中會更方便。更重要的是，當你在 MR 中檢視這些結果時，你會看到這些結果的「差異」檢視。換句話說，MR 中的結果會告訴你，與預設分支相比，MR 相關分支的測試和掃描結果有何不同。這一點非常有價值，因為它讓你知道你正在為分支貢獻的程式碼是否朝著正確的方向前進。簡單來說，你的提交是讓軟體變得更好還是更差？

當然，如果你等到完成編碼才建立合併請求，就無法從這種持續指導中受益。這本身就是建立 MR 在提交任何程式碼到分支之前的好理由。

合併請求促進團隊協作

然而，還有一個建立 MR 在開發流程早期的強烈理由：合併請求鼓勵團隊成員之間的協作。透過提供多線主題討論區域，MR 讓同事可以評論每次提交。你是否引入了微妙的錯誤？同事可以發現並提醒你在錯誤還容易修復時。你是否開始編寫一個不如替代方案快速的演算法？有人可以在你花費許多小時和行數編寫錯誤東西之前告訴你。你是否誤用了某些語言特性？如果資深開發人員能在過程初期指出來，你就可以在提交更多程式碼到分支之前調整風格。

這些情境都有一個共同主題：透過早期和頻繁地協作、評論單次提交中的小塊程式碼，問題會更容易發現並且成本更低來修復。MR 正是這種協作可以發生的地方。

理解 GitLab 元件

任何人都會知道，當被要求評論一個由3000行程式碼組成的完成功能時，會有一種沉重感不知從何開始。或者當你意識到開發者誤解了規範、沒有構建產品所有者所預期功能時所感到的絕望。或者當你不得不指出開發人員在功能程式碼中數百次犯下編寫或風格錯誤時所感到的尷尬。所有這些情況都可以透過頻繁評論小塊程式碼來避免，而這只能在第一次提交到達之前就準備好合併請求時實作。

三個朋友——問題（Issue）、分支（Branch）和合併請求

現在你知道很多關於問題、分支和合併請求的知識了。重要的是瞭解這三個 GitLab 元件之間緊密相關，當它們用來計劃並完成程式設計任務時。

GitLab 建議這三個元件的一種特定工作流程。他們建議在識別需要完成的工作後立即建立一個問題。一旦將該問題分配給開發人員後，開發人員應立即建立一個分支來進行工作，然後為該分支建立一個合併請求。問題、分支和合併請求應該都擁有類別似（或有時甚至完全相同）標題以顯示它們彼此相關。例如，如果你看到以下元件，從它們的標題就知道它們都解決同一任務：

  • 問題：簡化登入流程
  • 分支：simplify-login-process
  • 合併請求：簡化登入流程

內容解密：

合併請求在 GitLab 中起著重要作用。它們不僅僅是將程式碼從一個分支合併到另一個分支的一種方式，更是促進團隊協作和確保程式碼品質的一種工具。

  1. MR 作為儀錶板：MR 提供了一個集中的地方來檢視所有與程式碼相關的測試和掃描結果。這樣可以迅速瞭解程式碼品質。
  2. 差異檢視：MR 展示的是新分支與預設分支之間測試和掃描結果的差異檢視，幫助開發者瞭解他們正在做出的是正確還是錯誤。
  3. 促進協作：MR 提供了一個平台讓團隊成員進行多線主題討論，及早發現並解決潛在問題。
  4. 三個朋友：GitLab 建議使用問題、分支和 MR 的組合來管理開發流程，確保每個任務都有明確且可追蹤。

Mermaid流程圖

  graph TD
    A[建立問題] --> B[分配問題]
    B --> C[建立分支]
    C --> D[編寫程式碼]
    D --> E[建立MR]
    E --> F[進行程式碼評審]
    F --> G[測試和掃描]
    G --> H{測試透過?}
    H -- 是 --> I[合併到主分支]
    H -- 否 --> J[修復問題]
    J --> D

此圖示展示了從建立問題到最終將程式碼合併到主分支的整個流程。每一步都包含了必要的人工檢查和自動化測試，以確保程式碼品質。

Mermaid 分支結構圖

  graph LR
    A[主分支] --> B[特性A分支]
    A --> C[特性B分支]
    B --> D[MR-A]
    C --> E[MR-B]

此圖示展示了多個特性分支從主分支衍生出來並最終透過 MR 包括回主分支。

Mermaid 分析階段圖

  graph TD
    A[功能需求] --> B{程式碼編寫}
    B -- 是 --> C{程式碼提交}
    C -- 是 --> D{自動化測試}
    C -- 否 --> E{重新編寫}
    D -- 是 --> F{手動審查}
    D -- 否 --> G{修復錯誤}
    G --> B

此圖示展示了從功能需求到最終程式碼提交的一系列階段及其可能路徑。

內容解密：

  1. 流程圖：展示從建立問題到最終將程式碼合併到主分支的一系列步驟。
  2. 結構圖：展示多個特性分支從主分支衍生出來並最終透過 MR 包括回主分支。
  3. 階段圖：展示從功能需求到最終程式碼提交的一系列階段及其可能路徑。
  4. 跨切片須標記：每張圖表都涉及不同層面概觀上的不同範例

利用提交、分支及合併請求安全編輯檔案

在 GitLab 中，問題（Issues）、分支（Branches）和合併請求（Merge Requests）之間的關係非常緊密，這三者通常在完成任何編碼工作時都需要使用。因此，這些元素常被稱為「三個朋友」。如果你不確定如何開始一個程式設計任務，一個好方法是先確保這三個朋友都已準備好，然後再開始撰寫程式碼。

當兩個朋友足夠時

然而，並非每個任務都需要這三個元素。如果一個任務不需要編輯任何倉函式庫中的檔案，那麼就不需要建立分支，進而也不需要合併請求。例如，如果你的任務是為即將舉辦的企業活動設計 T 恤圖案，這些設計可以直接新增到問題的討論區域中。這樣不需要編輯任何檔案來滿足任務需求，因此你可以不建立分支和合併請求。實際上，建立分支和合併請求可能會讓你的同事困惑，因為這暗示著你期望編輯檔案來完成這項工作。

類別似地，有些情況下只需要分支和合併請求，但不需要問題。例如，假設你需要修復程式碼中的一個小錯誤。你可以建立一個問題來描述這個問題，但這對於這樣一個小修正來說可能過於繁瑣。在此情況下，簡單地建立分支和合併請求，然後進行一次提交來修正錯誤，並要求審核和批准合併請求似乎更為合適。大多數 GitLab 使用者會同意不需要問題（雖然製作問題也不會造成傷害）。然而，有些組織可能決定每個合併請求都需要相關的問題，這也是完全可以接受的政策，即使偶爾會導致一些額外的工作。

問題與合併請求的區別

你可能會問到問題與合併請求有什麼不同。我們已經討論過合併請求包含的額外資訊型別，但還有一個在概念上的不同之處值得注意。將問題視為提出和討論想法的地方；而合併請求則是展示和討論程式碼的地方。如果你使用這種概念來區分兩者，將有助於你理解何時只需其中一項或兩者皆需。它也能幫助你理解任何評論是更適合放在問題的討論區域（如果是在討論工作的一般想法），還是放在合併請求的討論區域（如果是在討論開發者交付的具體程式碼）。

另一個區別在於它們可以具有不同的狀態值。問題可以是開放或關閉；而合併請求則可以是開放、關閉或已合併。實際上，關閉的合併請求相當罕見，因為只有當你取消合併請求而沒有完成合併時才會使用這個狀態。那種情況偶爾會發生，但更常見的是合併請求在其相關分支被合併後轉變為已合併狀態。

理解 GitLab 元件

現在你已經看到如何使用 GitLab GUI 來處理基本概念如提交、分支和合併請求。也瞭解到問題與合併請求雖然最初看起來相似但擔負著截然不同的角色。你知道在提交任何編輯之前建立一個合併請求的重要性以及它們如何支援團隊成員之間頻繁且密切的協作。最後你瞭解了「三個朋友」如何協同運作以幫助你規劃工作、完成工作以及將任何結果程式碼進行整合。

此圖示

  graph TD;
    A[Issue] --> B[Branch];
    A --> C[Merge Request];
    B --> C;
    C --> D[Code Review];
    D --> E[Merge];
解密
  • 問題：代表工作任務或功能需求。
  • 分支：從主分支建立出來用於開發新功能或修復錯誤。
  • 合併請求：用於提交程式碼變更以便審查和整合到主分支。
  • 程式碼審查：團隊成員檢查並提供反饋。
  • 合併：透過審查後將分支程式碼整合到主分支。

強化 DevOps 應用流程

讓我們透過實際例子結束本章節探討問題、分支及合併請求如何協同運作以實作 GitLab 推薦的最佳實踐流程 - GitLab 流程（GitLab Flow）。這種流程被強烈推薦且已經經過時間考驗，甚至連 GitLab 也為此命名為「GitLab Flow」。當然我們鼓勵您將其視為開發自有流程及程式時的一個起點；根據需要對其進行調整以適應您團隊、產品及組織文化。

假設在開發 Hats for Cats 網路應用時決定新增一項功能讓使用者可以根據貓種過濾帽子；畢竟牛仔帽對於頭大的曼徹斯特貓來說可能會壓到精緻可愛的德文貓頭部上。以下就是按照 GitLab Flow 引導要實作該功能所需步驟：

  1. 在 Hats for Cats 小組下 Web 專案中建立一項名為「根據品種篩選帽子」之問題並保持所有後設資料欄位空白。
  2. 在該問題的討論區域提及兩位可能對此功能想法有意見的人。
  3. 兩位人員在討論區域回應；一人僅留下大拇指表情符號；另一人表達支援此想法但詢問應否根據其他標準進行篩選。
  4. 玄貓認為根據其他標準篩選是不錯點子；但還不確定那些標準應該是什麼？因此建立另外一項名為「疑問：篩選帽子應該使用哪些標準？」之問題暫時擱置處理；並專注回原始「根據品種篩選帽子」之問題因為品種確實是應該要包括的一項標準。
  5. 在團隊全體規劃會議上決定將此問題評估權重設定為 8 分；表示預計需要耗費 1 周時間完成；並指派給 Elizabeth 後端工程師負責並設定預計完成日期為今天起算兩週後。
次段落標題
  • 分析考量：
  • 初期需求：玄貓初步評估需根據品種做出篩選功能；
  • 追加考量：玄貓進而考慮其他篩選條件；
  • 專案評估：玄貓參與團隊會議完善專案內容與分配專案人員；
  • 專案計劃：玄貓制定專案計畫完善預計完成時間及發布時間。
小段落標題

  • 初期需求：

    • 應用開發過程中常遇到需根據使用者要求開發出特定功能供使用者使用；
    • 如本例中決定新增「根據品種篩選帽子」功能以方便提供客戶更多元化選擇；

  • 殘加考量：

    • 功能需開始階段通常只規劃出基本需求但隨著使用者使用多樣化需配套其他方案；
    • 本例中後續決定除了「品種」還需增加其他條件以讓系統更加完善；

  • 專案評估：

    • 團隊參與專案進行內部評估針對需評估技術可行性、預期成本及專案風險等進行詳細討論；
    • 評估中完善專案細節最終決定匯入進階功能；

  • 專案計畫：

    • 評估結果須透過專案計畫明確完善各階段目標達成時間；以及最後完成時間；
    • 號令提升專案管理效率避免延遲影響進度；
玄貓

玄貓

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