在上一篇([01]淺談Code Review的好處及意義篇 - 讓團隊彼此知道程式碼走向)瞭解了什麽是Code Review以及爲什麽可能會想要做Code Review之後。

下一個問題就是，如果真的想開始實行該怎麽做呢？

這一篇來介紹一下Pull Request的概念，以及如何協助做Code Review。

Pull Request是什麽?

在講Pull Request之前，必須先提到另外一個東西，也就是git。

git已經是一個顯學，尤其是在Open Source的領域裡面，不使用git host的open source原始碼應該不多見。

可是爲什麽大家都喜歡用git呢？尤其在open source的領域？

這個不得不提到git的殺手級應用，branch功能。

這篇不是git的介紹文章，不過簡單來説，在git裡面能夠透過開branch的方式，達到開發新功能的時候不影響現行的code，等到確認開發完成之後，在透過merge的方式把這個branch整合回到主要的branch。

這邊注意到一件事情，要把修改整合回去，需要透過merge的方式 - 那有沒有可能在merge執行之前，先停一下，要有個人去看一下程式碼，確認沒問題在確認執行merge這個動作。

這個停一下的階段就是所謂的Pull Request。

怎麽建立Pull Request?

上面瞭解了什麽是pull request之後，接下來就是要瞭解怎麽建立出pull request。

基本上每一個能夠host git的平臺都有pull request的功能，在這個系列將會使用Azure DevOps作爲範例 - 不過其他平臺(例如:GitHub、GitLab等)操作起來也是一樣的概念。

首先，還記得上面提到，把新的修改先建立在一個branch裡面。

git checkout -b feature/fix-readme

修改加上一些commit最後好了把這個branch push上repo

對ReadMe.md做一些修改、commit最後push上去

在Azure Devops找到 Repo -> Pull Request建立一個Pull Request

先進入到Azure DevOps的Repos功能裡面的Pull Request來建立：

可以從截圖上面看到，因爲剛剛push上去branch的關係，所以它有提示是否直接用那個branch建立pull request。

建立出Pull Request

這邊有幾個選項要選擇：

1. 選擇是哪個branch要合并
2. 要合并到那邊 - 一般是 develop或者master
3. title輸入這個Pull Request的標題 - 一般建議可以搭配把issue tracking號碼寫上去以及簡單描述
4. Description - 更詳細的描述 - 建議可以用pull request template (詳細可以參考：[01]讓團隊彼此知道程式碼走向 - 淺談Code Review的好處及意義篇)讓一切一致
5. 要給誰做Review - 可以多個人
6. 這個修改和那個Work item有關 - 如果有用Azure DevOps作爲Issue Tracking，那麽可以容易把需求和修改綁在一起
7. 按下Create按鈕

建立完成，進入review的畫面

按下create之後，會自動被帶入到做pull request review的畫面

這個畫面將是Reviewer接下來會操作的畫面。

結語

這篇介紹了什麽是Pull Request，並且如何建立出一個Pull Request。

在下一篇(Azure DevOps的Pull Request提供了什麽功能？)就是要瞭解Azure DevOps在Pull Request提供了什麽功能讓我們可以用來做Code Review。