延伸昨天的pull request繼續說，這是我非常喜歡Azure DevOps 的一個功能，就是合併是在這裡進行，而且可視化。當我們要進行pull request comptele的時候，你會需要選擇該如何併入你的 target 分支裡面。
最早以前我們在使用git的時候，從來就沒有思考過該用哪一種merge，反正併的進去就好，有衝突解決就好。其實那也是因為我們並不了解那些不同的合併方式到底會長成怎樣，反正最終交的出東西來即可。
但在這種狀況下，當越多人一起開發，branch 分支開越來越多的時候，很容易就會發生一個問題，那就是到底我這個commit的parent是誰？ 因為最基本預設的merge就是很單純的岔入target中，所以線圖就有可能會變得亂七八糟的，當然如果永遠向未來眺望，那也不用太在意那麻花般的線圖。
這次在Azure DevOps 的學習之路中，這個功能著實的讓我直觀的瞭解這四種合併模式，所產出的結果有所不同，因此用一點篇幅來說這個功能。
這就是最基本的，從你開始建立feature branch的base，岔出來的開發完後，就合併回target的現況。這就是我們如果選擇merge的預設，就可以簡單的完成任務，但如果是多人開發，就很有可能得到上面的線圖。
Squash commit 的特點就是，他會幫你把所有feature 上的軌跡，都合併成一個commit，然後放到target head的最前面。這樣的好處是，整個樹形會非常乾淨，而且你在feature branch如果有很多零碎的實驗，就不會被留存在軌跡中（其實還是查的到啦）。
這種其實很適合Feature branch 再併入Develop branch，原因是開發階段總有一大堆實驗，那如果太瑣碎，其實資訊量會過大，因此使用在這種場景其實很適用。而且也可以以這個Commit作為PR的依據，可以清楚知道Develop branch的每一個commit是清楚的被PR進來的。
Rebase and fast-forward 的特點就是，他會先幫你rebase到target 的head，然後把你feature branch的軌跡全部的commit都搬到target中。
但是對筆者而言，目前在我們公司的環境比較想像不到該用在甚麼狀況下，因為他會把PR的痕跡消失掉，就比較不容易知道這些被保護的Branch 是經過了PR而被放入。我唯一比較想的到的就是如果自己是多個Feature 在做開發，想要併成一個branch而已，但是這樣自己在本端做應該就好了，所以暫時比較想不到怎樣利用這種模式比較好。
這個模式目前是我們團隊最常使用的模式，他就是先幫你rebase 到target head後，幫你做了一個merge，並且新增了一個新的commit。
這種對我們的優點是，可以看到我們多努力XD，但卻又不會把整個圖形變得很混亂。不過這種我也很推薦，特別是從Develop 要併入main的時候，這樣可以清楚的知道是從Develop的哪一個commit被PR進入main。
有幸我們在今年初了解了這四種模式的用法，現在公司內先導專案的線形就漂亮多了：
上面那四種模式並沒有一定哪一種才是絕對該用的模式，這一且都還是取決於團隊或是開發者個人對於版本控管的看法，希望可以達到怎樣的線形，在管理上才好說明，或是好追蹤。
另外一說就是，project可以針對repo中的branch，限制只能使用哪一種merge type，位置如下：
那表示未來我可以針對main branch 要求只能使用semi-linear merge，這樣可以清楚辨識develop branch併入的時機。
在選好你的merge type的時候，下面會有個選項，Delete XXX after merging，如果是併入develop branch的時候，請習慣性地一定要把這個勾起來，把不需要用的feature branch 在使用後刪除，比較不會造成困擾。
另外就是，由於並不是在自己的開發機器的git上面進行merge的動作，因此記得switch 回devlop branch，然後把地端的feature branch也要一併刪除。不然又推上去就很可能會造成版本錯亂，雖說develop branch是被保護住的，但是開發遇到這種阿札的問題總是讓人很不爽，所以這個小小的習慣要建立起來。
由於Pull request已經結束，所以feature branch 已經被合併進入develop branch了，上圖可以看到，develop branch的更新觸發了pipeline進行CI/CD的動作。
這時候我們只要等著pipeline跑完，就可以告訴使用者這個項目已經交測了。但記得，去關聯的user story #18 做兩件事情：
終於！第一次交付測試了！！
iThome鐵人賽
看影片追技術