交付到測試環境

當我們認認真真的完成了一個使用者的願望的時候，表示我們完成了一個User story的項目，也就是可以把它放到測試環境去，請使用者根據當時雙方協議好的驗收標準去進行測試了。

那之前有說到，我們的測試環境其實就是用Develop branch去面向的，所以我們在這個branch 是有設定policy，這就是為何昨天一定要另外開一個Feature branch來進行開發的動作，因為如果你在Develop branch commit之後，git push 一定會被拒絕。

因此，我們要開一個Pull Request，進行審查後，才可以把寫好的程式碼併入Develop branch中。

Pull Request

在昨天的案例中，我舉了#22 修正後端API外，我另外也把#21 與 #23狀態也都切換到了Closed的狀態，以這樣來表示一份User story 相關工作項目都開發完成，並且準備提供使用者進行測試。

上圖可以看到的是如何發動一個pull request，那因為新命名的Feature Branch名稱 Feature_API 是我最新Commit的，所以他上面會出現提示告訴你Feature_API 來進行pull request。

上圖就是要開一個新的pull request的表單，最最最重要的，就是要看紅色圈起來的部分，就是你的feature branch 是要併入Develop，而不是main，搞錯了其實一開始也不會怎麼樣，但如果後續reviewer 眼睛閉閉也就按下去了，那你的程式碼就會快樂地被發動併入main，就有可能觸發自動佈署到正式環境的窘境了，不可不慎。

其他的資訊基本上就是填一填，包含這次申請的標題、敘述、審核人員。我在Description 的時候特別加入了#18 這個user story，就是要表明我這次是為了要驗收這個項目。另外下面的work item 相關的 #21 #22 #23，是自動被關聯進來的，這是因為在commit的過程中，我們有把它寫在message中，因此在發動pull request的時候，也就自動的被帶入了。

那因為link是雙向的，因此當pull request被create之後，#21 #22 #23也會被link回來。這樣在查閱那些task的時候，就會知道除了經過哪些commit以外，也經過了這次的pull request，這樣在做變更管理追蹤時，可以直觀的把相關的事項都找出來。

好，我們按下create。

Review

這一頁資訊量有點大，所以一個個區塊說明：

1. 這部分是敘述我希望把Feature_API 這個branch 併入到Develop。
2. 區塊二這裡有許多個頁簽
   1. Overview 就是這一頁Form。
   2. Files 則是讓你可以看到這次的併入，跟Develop branch有差異的檔案。
   3. Updates 要把它看成，有哪些人分別Push 了幾次，造就了這次的pull request。
   4. Commits 則是pull request到底有多少個commits，這跟updates其實很接近，但是要呈現的資訊還是有一點不同。
   5. Conflict 這是一個第三方套件，剛好前陣子有遇到衝突問題，發現pull request在這裡做，衝突竟然要線下解決太麻煩了，最後找到了這個套件。後面如果有空再來說。
3. 區塊三這裡是指自動檢查點，等等展開來說明。另外系統也會檢查conflict問題，在這裡是沒有衝突。
4. 這是之前在填寫的時候的敘述。
5. 這邊是reviewers，我在develop並沒有強制指定reviewer，但如果在這階段希望把reviewer加入，也可以指定，但是因為branch policy並沒有強制要求要幾個人review，所以即使指定後沒有review，那也是可以完成。
6. work items，就是這次有連結的那些工作項，在這裡我們也可以把user story #18 也給link進來。

這邊針對files 的部分來稍微細講一下這個功能，其實這個功能應該是整個pull request的檢視程式碼主頁，針對項目的地方說明一下：

1. 區塊一的部分，會呈現出這次pull request ，跟target branch (這裡是develop branch）所異動的所有檔案，而每個檔案在滑鼠滑過去的時候，都會出現checkbox，可以進行勾選表示reviewed。
2. 區塊二的部分，就是diff，這裡最重要的是，你可以針對你有意見的程式碼該行，進行comment的新建，而且comment是有狀態的。這意思是，有review針對review的結果提出了意見，pull request 的發動者就有義務針對該意見進行回答。可以從Overview 看到comment如下，那如果回答了之後，就可以把狀態變更，設定為解決。

另外也可以看到，由於有一個comment沒有被回復，最上面的Require check succeeded就跳出了一個 1 optional check failed，那右邊的checks可以看到，我們在 develop branch 有設定兩個policy，一個是work items must be linked(強制規定：修改必要有所本），另外一個是comments must be resolved(要解決reviewer的意見，但是是選擇性的）。

Complete

本來pr想要講更多，不過因為既然是SDLC，所以到時候要pr到main，面對營運環境的時候，我們可以再把投票機制講更多一些，讓我們先按下complete的按鈕，接下來會跳出Complete pull request的頁面。

這裡先簡單介紹我選了merge type 為semi-linear merge，那在這裡可以選擇一些在完成之後的自動化選項：

• 將所有的有關的work item狀態都設定為完成：因為我這只是進入develop，所以不勾選。
• 刪除掉feature branch：這個必須勾選，我後面再花一點篇幅說明我們目前操作的方式。
• 客製化merge 的message：這個就看個人，如果有客製的需求，可以依照merge type類別考慮是否要使用。
  

Pull Request是重要的審查工作，是確保程式碼品質的重要關卡