Require a minimum number of reviewers

這個設定將決定：總共有幾個Reviewer要投Approve才能夠過Pull Request。

透過這個設定，能夠規定幾個人看過才算過。

這個設定還有幾個細節：

1. 這個數字設定，最少有幾個Reviewer看過才夠
2. 是否允許建立Pull Request的人算一個Reviwer - 有時候假設規定一定要有1個Reviewer看過，但是剛好大家都忙，那麽有勾選這個讓自己可以approve過然後complete就變得很重要
3. 如果Reviewer的決定是Waiting For或者Reject，是否還是可以過
4. 如果有Reviewer已經投狀態了，但是有新的update，是否要把他們的狀態reset

Check for linked work items

這個設定將決定：Pull Request是否一定要綁定work items。

很多時候某個修改不知道爲了什麽而改，如果每一個修改一定會對應到一個issue，那麽這個設定就變得很重要，因爲可以規定是不是一定要綁work item。

這個設定還有子項，可以覺得是硬性規定還是可選規定。

Check for comment resolution

這個設定將決定：是否所有的Comment都要Resolve

不管是針對某一個程式碼下comment還是針對overview裡面寫comment，每一個comment預設狀態都是un resolve。

這個設定就可以決定，是不是都一定要resolve才能夠complete。

和上一個一樣，能夠決定是不是硬性規定還是可選規定。

Limit merge types

當complete要merge回去的時候，可以選擇要用什麽方式merge回去。

這個設定就是：鎖定可以選擇哪幾種merge方式。

預設開啓4種方式：

1. Basic Merge - 這個就是一般的git merge --no-ff
2. Squash Merge - 把所有的commit壓縮成爲1個commit然後merge
3. Rebase and Fast Forward - 透過rebase然後一般的merge - 最後結果是commit tree永遠是一條線 - 個人不推薦
4. Rebase with Merge - 透過rebase，然後做一個--no-ff的gommit

這個就看團隊的git分支的策略來選擇就好。

Build Validation

一般來説，要merge回去之前一定會想要知道，這個branch是否build會成功。如果build成功，其實連看都不需要看了。

這個要搭配Azure Pipeline，如果Azure Pipeline有設定Build Definition，這邊就可以選擇要用那個Build Definition。

Require approval from additional services

這個服務沒有使用過，不過看起來可以透過打一些狀態到Azure DevOps來，然後在依照這個狀態決定是否能夠過。

應該可以用這個搭配其他服務，然後透過打狀態的方式整合別的服務來決定是否透過pull request。

Automatically include code reviewers

在公司内部可能有些人是特別負責審核某些程式碼，這個時候可以透過設定，只要有建立Pull Request他會自動被設定為Reviewer。

這個設定就在設誰要變成自動加入的Reviewer。