【Git】基本運作介紹：分支（branch）、Git Flow、Commit、PR、Code Review、merge&解衝突
那個，標題好像有點太長
最後更新時間：2024–09–30
前言
在【Git】Git 是什麼？版本控制？介紹了版本控制觀念，接著我們繼續往前，在進入指令介紹前還有些事情要做，其中一件就是本篇的基本運作介紹，先對一些東西有概念後才知道指令在幹嘛，而接下來 Git 的文章很多會引用高見龍大大寫的為你自己學 Git，這是一本書、課程、同時也是個網站，裡面有許多免費文章資源可參考，不僅圖文並茂而且寫得夠白話，我個人很推，也歡迎大家去那個網站看看。
如同上次那篇說過的，其實今天講的這些主題都能獨自寫一篇去探討，以後有機會再深入去談，本篇先介紹基本觀念。那就按照慣例先進一段說文解字時間（志祺七七的這句話好像滿好用的）。
說文解字
上次講了 Git 滿好笑的命名考量，這次想挑 2 個字來講，而 PR（Pull Request）因為名稱跟使用者行為高度相關則留在下面 PR 的時候一起談。
1️⃣ branch
這個字有啥好談的，不就一個很簡單的字？對，單純想嘴一下口音這件事XD。branch 是分支，就像是程式碼主體的不同分身擔任不同角色，有的分支負責主開發、有的負責測試、有的則是穩定發布的版本，後面會再談到。而 branch 在銀行則常指分行的意思，之前外派到東南亞某國時，第一次聽當地主管（不會講中文）在談一些分行的事情時聽不太懂，對方一直發出類似「布朗」的發音，當時實在有點受不了就問說「布朗」是什麼，身旁待比較久的台灣同事才說對方意思是 branch，我才意識到對方直接將 ch 的音省略而且還把 [æ] 發成 [ɑ]，於是我就很不要臉地糾正對方發音並且重複唸了幾次給她聽，後來想想這樣不太好，因為其實對方職等高了我好幾級而且又是主管，以金融業而言似乎有點不禮貌，但如果不馬上講好像也沒啥機會說就是了。
之所以對「口音重」這件事特別感冒是因為我主觀且充滿偏見地認定口音重某種程度隱含了對方的自私程度，而這件事我從以前就這麼認為，到現在也沒改變多少。有口音是再正常不過的事我自己也有口音，可是學語言不就是為了溝通嗎？如果口音重到其他國家的人聽不懂你在說啥那有達成溝通目的？口音是需要下苦功去練的，不斷去聽英語系國家的人怎麼發音並且持續練習，而口音重的人我就是認定對方沒有或不想下苦功去練，反正劈哩啪啦就把英語講出來，魔改成自己想要的發音根本不在乎其他人聽不聽得懂，這就是為什麼我認為這是自私的展現。再次強調，這是我個人主觀且充滿偏見的意見XD。
2️⃣ commit
這個動詞有滿多意思的，像是承諾、犯 XX 罪，根據劍橋字典以下這些意思或許跟 Git 會更相關：
to express an opinion or to make a decision that you tell people about
to make certain that you remember something
to write something down
所以 git commit 就有點像是將你對程式碼變更的「確認」提交到版本控制系統中正式記錄下來，相當於告訴電腦「欸欸我已經確認了這些變更，幫我記一下」
分支（branch）
嘴完別人口音後再來正常地談談分支。分支是什麼？高見龍大大這篇譬喻得很貼切，就很像程式碼本體的影分身之術，每個分支其實就是本體的分身，只是依照功能會有點點不同。那為什麼要有分支啊？很簡單，才不會三不五時就把真正重要的本體改壞，想想看，如果你只有一個本體而且 CICD 做得很好每次上新功能就自動整合與部署，只要一改程式碼全部的人就馬上看到更新，如果沒事就沒事，那萬一有錯呢？萬一協作時程式碼有衝突呢？一想就超恐怖。多人團隊如果有分支就會更好協作，大家可以從主要分支切出功能（feature）分支各自開發，只要不合併到主分支就不會在開發過程彼此影響，合併過程也可以有審核機制。既然講到分支就不能不談 Git Flow。
Git Flow
如果你會影分身而且這些分身合體後你都能得到他們的經驗值，那你會想要怎麼分配這些分身？如果是我可能會讓一些分身去學習、一些負責工作、另一些則去做雜事，而我這個本體則負責玩✌️（喂），那如果能讓程式碼影分身，你想讓不同分身去做什麼事呢？
這個所謂「讓不同分身負責不同事且彼此如何合作」的方式其實就是 Git Flow 在談的事，關於 Git Flow 我有寫過，可以參考這邊，或者參考高見龍大大的這篇。
既然是流程那就不會只有一套，其他的還有 GitHub Flow、Gitlab Flow 等，不過我只用過 Git Flow 跟現職公司這套所以也無法分享得太詳細，簡單去瞭解一下後用很白話說明就是 GitHub Flow 沒有分太多分支，就基於主線去開發變更的部分再合併回去，而 Gitlab Flow 則是 Git Flow 與 GitHub Flow 的平衡版，不像 Git Flow 那麼多分支但也不是 GitHub Flow 只有一個主線，而是 1 條主線 + production & stable 分支的模式，如果想進一步瞭解最快的方式就是看圖，但我懶得畫圖所以推薦以下這兩篇覺得圖畫得簡單明瞭的文章：
Commit
剛剛說文解字講過了，反正就是每筆你想記錄的程式碼變動，而 Commit Message 就是使用 git commit 指令時你寫下的東西，例如「增加 A 功能」，至於 Commit Message 有哪幾種寫法慣例、怎麼寫比較好、粒度（Granularity）要多大未來有機會再分享。
PR（Pull Request）
簡單說就是將程式碼變動提交與合併的動作，想想看，commit 之後總需要將變更的地方放到主分支吧，不然自己寫完就放在自己的分支別人也不知道那不就寫心酸的？所以通常都是多人協作才有這件事，如果是一人開發要發 PR 也不是不行，只是自己寫的東西發 PR 審的人也是自己，一個裁判球證旁證都是我的人你怎麼跟我鬥的概念，沒有啦開個玩笑，一個人當然也可以用上面介紹的各種 flow 去管理分支。
對了，在台灣比較常聽到「發 PR」，其實就是 create / open a pull request，可是為什麼要叫做 Pull Request 啊？其實跟這個行為本身有關，當你做了一個新功能想提交到某個分支，基本上你就是發出一個請求（request），而這個請求是要請求什麼呢？就是請求對方把這個功能拉（pull）到該分支上，因此 PR 就是一個 pull 的 request，關於 PR 的介紹一樣首推龍大大的文章，寫得清楚明白。
Code Review
發完 PR 就可以去慶祝吃火鍋囉～才怪，有人發就有人審，這個審核過程就是 Code Review，字面意思白話到不行，就是去 review 你寫的 code 看有沒有問題或哪邊可以優化，要怎麼好好地 Code Review 也是個學問，這邊先不展開，不過可以稍微說一下現在 AI 越來越發達，像之前參加個研討會好像是說 Azure DevOps 也有請 AI 協助 Code Review 的套件了，大概可以先把一些低級錯誤篩掉，甚至在本地端 git commit 時就能先做這件事，只是這部份我還沒什麼研究就不大放厥詞了。
merge & 解衝突
Code Review 後如果沒問題對方就會 approve，那之後呢？是不是就可以把程式碼放進去了，這個放進去的過程就是 merge（合併），而此時如果沒事就很順利，但如果功能較複雜且同時多人協作大家都有各自更改的地方，到時合併就會出現部分程式碼不一致，而這就是衝突（conflict），現在不管是 Azure DevOps 或 VSCode 其實解衝突的設計都滿直覺的，跟著畫面操作應該沒啥大問題，通常會跟你說哪一段有衝突、該段現有程式碼是啥而你的又是啥、想保留哪一個等等，別緊張。
解完衝突並且成功 merge 後，接著就看團隊有沒有建立 CI/CD 流程，我目前待過的團隊都有 DevOps 會負責相關任務，所以其實到了這步之後通常不太需要操心後續流程，例如自己還要去部署幹嘛的，唯一需要稍微看一下的就是觸發 CI/CD 相關 Pipelines 的過程中是不是有什麼問題發生，例如因為 XX 原因卡住了，可以自己先看一下 error message，但像我這麼菜而且對 DevOps 完全不熟的人通常是看不太懂，所以直接請 DevOps 去看比較快。
那如果 merge 也順利的話，接著就看團隊的分支管理政策是啥、採取什麼 flow（上面講的那些 XX flow 或公司自訂），看有沒有需要針對一層一層的分支合併再去發 PR，總之 CI/CD 流程跑完後程式碼順利部署就大功告成囉，其他監測什麼的便屬於其他議題。
結尾
對於各種名詞有個概念後就可以接續往後看了，下一篇會談到 Git 安裝、啟動、怎麼從 GitHub 拉 repo 下來、設定上游等等，到時見囉。
其他 Git 文章
