GitLab: Commit & Merge Request
本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。
本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。 鐵人賽原文網址：https://ithelp.ithome.com.tw/articles/10217957）
我們假想情景中的 Developer 今天已經解完ㄧ張 Issue，現正準備送出 Commit 與 Merge Request。
Commit 與 Issue
為了解決 Issue #5，Developer 首先遵守 GitLab Flow 先由 develop 建立了名為 5-payment 的 Feature branch。
（遵守規則，在新建立的 Feature branch 上進行開發。）
接著，為了解決 Issue 5 總共送了 2 次 Commit。為了讓 Commit 與 Issue 自動建立關聯，在 Commit Message 中，Developer 都主動提及了 Issue 的編號。
（只要以 # 搭配 Issue 編號，GitLab 就會自動將 Commit 與 Issue 建立連結。）
（只要有在 Commit Message 提及 Issue 的編號，GitLab 便會自動在 Issue 的詳細內容顯示有哪一個 Branch 與此 Issue 相關。同時 Issue 的異動歷史資訊也一樣會自動顯示有哪些 Commit 與此 Issue 相關。）
Merge Request 與 Code Review
接著 Developer 準備要送出 Merge Request。
（GitLab 會主動在 UI 介面上提醒你剛才有 Commit 程式碼，主動詢問你是不是打算要 Create merge request。）
（建立 Merge request 時，GitLab 會主動根據 Commit message 帶入 Title 與 Description 的內容。）
（GitLab 在 Description 或 Comment 的線上編輯器具備即時提示的功能，只要輸入 # 就會立即顯示有哪些 Issue。）
（線上編輯器也具備 Quick Actions 功能，可以便捷的控制 GitLab 自動執行某些動作。例如這個 Merge request 要 Assignee 給 Senior Developer 處理，除了可以用下方的 UI 介面 Assignee 以游標去點選目標 User，也可以直接在 Description 中用 /assign 標注目標 User。）
由於 GitLab 已經與 Mattermost 整合，因此當 Developer 送出 Merge request 之後，Senior Developer 立即就在 Mattermost 的 Channel: merge-request 收到通知。
（會顯示 Merge request 是由誰發出，並將相關連結一併附上。）
（被 Assignee 處理 Merge request 的 User，在他的 To-Do List 上，也會自動列出這項工作。）
Senior Developer 立即抽空查看目前送上來了程式碼，看完之後只能搖搖頭，這樣的品質可不能讓它通過。
（Merge request 的介面一樣有提供 User 討論的空間，像是可以針對 Merge request 直接用「讚」與「差」來表達意見。）
（負責 Code review 的 User 可以在 Merge request 的 Changes，直接針對某幾行程式碼撰寫 Comment。）
（針對程式碼的 Comment 也會自動整併在 Discussion，並且成為待解決的 thread）
由於 Merge request 被打回票，需要解決 thread，因此 Developer 在修正之後，又送了一次 Commit，並且在 Discussion 表明自己已解決 thread。
（後續送上來的 Commit 一樣會自動關聯在 Discussion 中，方便 User 查看。thread 提及的程式碼如果有產生異動，也同樣會自動顯示歷史資訊於 Discussion 中。）
再次 Code review 確認沒有問題之後，Senior Developer 按下 Merge 按鈕，程式碼順利合併，並且自動開始進行 develop 的 CI Pipeline。
（Merge request 與 CI Pipeline 也會建立關聯，GitLab CI 也可以達成先跑某個特定的 CI Pipeline，一但通過就自動 Merge 的流程。）
再一次的 Mattermost 的 Channel 又自動推送了訊息，通知團隊成員們這個 Feature 已經順利 Merge。
與之同時，Issue 5 也被 GitLab 自動 Closed。
（只要在 Commit message 或 Merge request 的 Discussion 中有撰寫 Close + Issue 編號的字串，GitLab 就會在 Merge request 順利通過的時候，自動幫你把 Issue close。）
小結
今天我們繼續跟著假想情境的 Developer 與 Senior Developer 工作，看了一下他們是如何利用 GitLab 的 Merge request 功能進行溝通協作，順利將 Issue 解決。
GitLab 提供了些便捷的功能，能夠半自動的在 User、Issue、Commit、Commit Message、Merge request 之間建立關聯，如善用這些功能，將能為團隊在開發工作的溝通協作及效率上提供一些助益。
另外，就如我們在早先的文章亦有提過，GitLab 能夠與 Mattermost 這套非常類似 Slack 的團隊溝通協作工具串接整合，Project 上的任何異動狀況都能主動的推送至 Mattermost，即時通知 User。不用擔心會漏接任何異動資訊，你反而要擔心資訊過量，需要評估哪些層級的資訊不用傳送至 Mattermost。
今天的分享就到這邊了，看來我們假想的開發團隊正持續地向前進，接下來她們還會遇到哪些狀況呢？鐵人賽，我們明天見～