![[05][讓團隊彼此知道程式碼走向]如何强制走Pull Request以及設定符合規則才能合並分支.jpg](/posts/2019/06/2019-06-11-code-review-05-force-use-pull-request-and-set-rules-before-pull-request-can-be-complete/2fe0b23e-7ffa-4d3c-99e6-cacf5b54253b.jpg)
在上一篇([04][讓團隊彼此知道程式碼走向]整合的威力 - 整個Review的過程)介紹完了整個Code Review的過程，從最一開始的需求，到修改好之後，透過Pull Request做Code Review然後把修改合並回主線。
基本上所有的功能基本都會使用了，但是還有一個很大的問題：如果開發者不走Pull Request的話一切不都完了？
這一篇將來看一下，如何强制要求一定要走Pull Request，並且一些設定讓Pull Request一定要有符合某些條件才可以結束。
![[04][讓團隊彼此知道程式碼走向]整合的威力 - 整個Review的過程.jpg](/posts/2019/06/2019-06-08-code-review-04-integrate-together-flow-of-code-review-from-issue-to-complete-in-azure-devops/f3c2a321-d60a-4e4f-9568-fd025c4b1fe7.jpg)
在上一篇([03]Azure DevOps的Pull Request提供了什麽功能？)瞭解了整個Azure DevOps的Pull Request功能之後，接下來就是看看在實際上如果整個串起來是什麽感覺。
這篇將從做一開始的需求，到最後整個功能確認修改好並且合併回主要分支。
這一篇也希望可以看到Azure DevOps這種一整套整合好的工具的好處。
![[03][讓團隊彼此知道程式碼走向]Azure DevOps的Pull Request提供了什麽功能？.jpg](/posts/2019/05/2019-05-29-code-review-03-azure-devops-pull-request-functionality/20593d82-928b-44fd-9d76-c3531686ac3c.jpg)
在上一篇(何爲Pull Request並且如何建立 - 以Azure DevOps爲例)介紹了如何透過建立branch來把修改獨立出來，並且在修改完成之後透過建立Pull Request的方式建立出可以Code Review的一個請求。
這一篇將來看看Azure DevOps裡面的Pull Request包含了那些功能。
![[02][讓團隊彼此知道程式碼走向]何爲Pull Request並且如何建立 - 以Azure DevOps爲例.jpg](/posts/2019/05/2019-05-19-code-review-02-what-is-pull-request-and-how-to-create-it-in-azure-devops/cff4d33d-d173-45eb-9810-afad50964211.jpg)
在上一篇([01]淺談Code Review的好處及意義篇 - 讓團隊彼此知道程式碼走向)瞭解了什麽是Code Review以及爲什麽可能會想要做Code Review之後。
下一個問題就是，如果真的想開始實行該怎麽做呢？
這一篇來介紹一下Pull Request的概念，以及如何協助做Code Review。
![[01]淺談Code Review的好處及意義篇 - 讓團隊彼此知道程式碼走向.jpg](/posts/2019/05/2019-05-05-code-review-what-is-code-review-and-why-we-want-to-do-it/32232b4c-0ff0-4378-9967-38393bfc0160.jpg)
程式碼對於工程師來説，就像是自己的小孩一樣，要時常的關心它，如果不怎麽做很容易導致長歪。
當程式碼還只是自己維護的情況下，掌控肯定很高，畢竟只有自己在開發而已，但是當是一個團隊在開發的時候，怎麽掌控或者知道走向就變的很重要。
這也就是Code Review的主要目的，這篇來看一下爲什麽要做code Review，Code Review要看什麽，以及有什麽工具可以協助這一件事情。
_1477.png)
_1485.png)
_1486.png)