前情提要
為什麼要寫這個系列文？原因請見系列文第一篇。
那這次要寫什麼？
這次為 Git，就是版本控制，應該是個新手普遍很不熟的主題，當然包含我在內因為我也是新手。為什麼新手大多不太熟 Git 啊？自己列出這個問題後也思考了一下，回顧學習過程想想也滿正常的，寫出來的東西沒多複雜自然不會用到太多版本控制，我用到最多 Git 是之前做多人協作專案時，當時其實滿抖的，深怕一個不小心改到其他協作者的內容，所以協作前還自己開個 repo 練習。總之，這次的兩個畢業技術考題跟 Git 有關，來看看吧（雖然標題的前端技術考五個字應該已經篩過一輪，但如果你剛開始學程式還沒碰到版本控制且不小心點進來，建議直接跳過這篇吧）。
1️⃣ Git
【題目】
我們的 Git 歷史呈現如下圖，現在我們想要把 dev 合併回 master，在過程中會發生程式碼衝突，請依序列出：
- 使用 git merge 來合併的流程與必要指令
- 使用 git rebase 來合併的流程與必要指令
【我的回答】
（以下以 VS Code 實作）
git merge
- 先用 git checkout master 切回 master。
- 再用 git merge dev 把 dev 合併回 master。
- 若無衝突則會直接 merge，若有衝突則畫面會顯示有衝突的地方，此時可以發現終端機上分支的位置寫著「(master|MERGING)」，可以選擇直接在畫面修改或按「Resolve in Merge Editor」進行修改再按 Complete Merge。
- 解完衝突後，再次使用指令 git add . 與 git commit，完成後就 merge 成功並且終端機上分支的位置變回「master」。
git rebase
- 看要在哪個 branch 以誰為基準去 rebase，例如在 dev 分支使用 git rebase master 或在 master 使用 git rebase dev，以結果來說 rebase 後是一樣的，但是 commit 紀錄的順序會有所不同。以下就在 dev 分支使用 git rebase master。
- 如果有衝突，終端機會顯示步驟，而此時終端機上分支的位置寫著「dev|REBASE 1/3」（看會有幾個 commit 要比對），而且一樣可以選擇直接在畫面修改或按「Resolve in Merge Editor」進行修改再按 Complete Merge。
- 解完衝突後使用 git add . 後並輸入 git rebase — continue，接著會進入 Vim 編輯器，想改 commit 名稱就修改，修改完按 Esc 鍵並輸入 :wq 即完成，若不想修改就直接輸入 :wq，完成後會回到終端機原本畫面並進行下一輪比對，分支位置變成「dev|REBASE 2/3」，之後就做一樣的事直到 rebase 都結束，分支位置就會變回「dev」，基本上 rebase 已完成。
- 此時，dev 會是 rebase 後的最新版本，然而 master 還未更新，因此使用 git checkout master 回到 master，並輸入 git merge dev 將 dev 合併回 master，這樣 master 即為最新狀態。
【補充說明】
當時這題因為一步步試著做花了不少時間，尤其進入 Vim 編輯器後會很緊張，有種無意間闖入異世界想著怎麼趕快回到正常世界的焦慮。git rebase 指令操作過程寫得特別清楚是因為自己以後也可以看XD，不過 Git 這種東西真的要動手做才清楚，用看的看完可能也是不會做，另外，我當時刻意練習在終端機用指令方式操作，一邊搭配圖形化介面來確認自己認知是否正確（我用的是 Sourcetree，一間叫 Atlassian 的公司做的，它還有其他有名的產品如 Trello），想刻意練習的話這個方法還 ok，大家可以做做看。
【參考資料】
另一種合併方式（使用 rebase）
Git | 我以為的 Git Rebase 與和 Git Merge 做合併分支的差異
分支的合併
繼續閱讀 | 回到目錄
2️⃣ Git Flow
【題目】
以下是一個 Git Flow 的示意圖，請你解釋圖中每個分支的使用情境 (遇到什麼情境，你會在該分支上工作)
在題目這邊岔題一下，不知道大家看到這種流傳廣泛的圖片，如果裡面有原始資料來源會不會好奇輸入網址去看看那邊有什麼？我就幹了這件事，其實滿怕連到奇怪網站但又覺得這麼多人看過如果有事應該會有人知道？而且網址看起來沒有奇怪的釣魚文字，總之因為好奇心還是試試看。如果點進 http://nvie.com/archives/323，會發現網頁以迅雷不及掩耳盜鈴之勢跳轉到另一個網頁，如下：
網頁會跳轉到 A successful Git branching model，2020 年時作者還補充一些關於 Git Glow 的反思，滿有意思的。網站右上角有 About，可以知道作者是位來自荷蘭的大哥 Vincent Driessen，仔細一看還能發現他開了間接案公司叫 3rd Cloud，哇靠點進去一瞬間還以為中毒勒，這個網頁也太簡便了吧而且整片藍底白字嚇我一跳，不過稍微看一下裡面還有作者本人的 LinkedIn。總之，今天當了一下小小柯南（並沒有，就只是肉搜而已），謝啦 Vincent 哥。
【我的回答】
以下依圖片中出現順序由上而下進行說明
- master：即主幹，存儲穩定、可發佈的程式碼版本，其他分支開發完會合併回主幹（基本上只會有 hotfixes 或 release branches 直接合併回來，develop 會先到 release branches，而 feature branches 則先到 develop）。
- hotfixes：用於緊急修復，修復完成後將其合併回 master 和其他相關分支，以確保問題得到解決。
- release branches：在準備發佈時可從 develop 分支建立一個 release 分支，通常用於最後測試和穩定性驗證，一旦準備好，release 分支就會合併回 master。
- develop：即為一般開發分支，用於進行日常開發，若完成則會從這邊建立上述的 release branches，確認沒問題才會再進一步合併回 master。
- feature branches：開發人員可從 develop 分支建立自己的 feature 分支，並在該分支獨立進行開發，開發完成後 feature 分支就會被合併回 develop 分支。
【補充說明】
老實說自己沒這樣分過，多人協作時我們 branch 弄得有點亂，而事後檢討時也將這點列為以後改進事項。這個模式相信是無數前輩們累積下來的最佳實踐，很期待之後可以依照這個方式實作。這題當初是直接問 ChatGPT，因為這種定義型的問題問它最有效率，後來也找了兩個參考資料給大家參考。
【參考資料】
Git Flow 是什麼？為什麼需要這種東西？
Git 和 Git Flow 是什麼？如何應用？
繼續閱讀 | 回到目錄
結尾
本來寫完題目的部份發現篇幅有點短想要補充一些 Git 筆記，但又覺得這樣太發散，筆記比較適合另外發一篇像是什麼適合新手的 Git 筆記之類，到時候再來想個農場文標題，ㄎㄎ。以下也附上系列文的其他篇，歡迎參考。
