在團隊中使用Pull Request來管理代碼
前言
在參加多人共同開發項目，且選用Git作為代碼托管工具的時候，我們不免會遇到分支沖突、覆蓋、合並等問題。顯然，因為同一個倉庫是屬於大家的，所以每個人都有權限向倉庫中push或者pull數據。但是這樣難免會帶來混亂，在人數較多的時候，更是容易出現問題。
目前，在很多團隊項目中，都使用Pull Request（GitLab稱為Merge Request）來進行Code Review。Pull Request是一種有效的管理源代碼的方式，尤其是在許多人一起貢獻源代碼的時候，顯得尤為重要。
Pull Request的優點：
- Auto Merge功能。哪怕兩份代碼並非在最新的master分支情況下進行修改，Pull Request也會智能識別，將多份來自於不同分支的代碼進行合並。
- Code Review功能。開發者提交上去的代碼可由管理者進行復審。復審過程中出現的任何問題，可以直接在commit中進行指出，也可以引用相關代碼行來指出問題，交流方便。
- 與Issue的綁定功能。Pull Request可以與Issue進行綁定，相當於指定了完成某個Issue所修改的代碼，在回顧時可以較為清晰的看到代碼變化。
下面，將介紹Pull Request模式的工作流程。
提出需求
所有的任務、需求、Bug修復都以Issue的形式呈現。管理員、開發者、測試員等都可以創建Issue。
Github的創建Issue界面如圖所示，左側主要填寫需求的具體內容，支持Markdown。
右側可以將需求直接指派給某位開發者。如果不指派，開發者也可以選擇認領任務。
右下角有Linked Pull Request，可以將與該Issue相關的Pull Request與此Issue構建聯系，若Pull Request通過，則代表該Issue被完成。
開發者操作
在該工作模式下，master分支是受保護的——任何開發者都無權直接修改master分支，哪怕是管理員也不應當對master分支進行直接修改，否則會造成混亂。
那么，如果開發者想要修改master分支中的內容怎么辦呢？
-
從master分支創建出去一個屬於自己的分支，用作開發者自己進行調試的開發環境。
開發分支的建議命名格式：操作者姓名--操作內容，如guojun--add-readme。千萬不要命名為dev1，dev2這種毫無信息量的名字，否則修改記錄將難以追溯！
(master) git checkout -b guojun--add-readme -
修改開發分支中的內容，本地測試，push到開發分支。
(guojun--add-readme) git add --all (guojun--add-readme) git commit -m "add README.md" (guojun--add-readme) git push -u origin guojun--add-readme -
最重要的一步，提交Pull Request到master分支。
你可以輸入一些關於這個PR的說明，以供其他人進行Review。
PR上傳之后，等着組內專門的Reviewers來進行Review吧。
對於不同的倉庫，例如前端、后端等，Reviewers可以是測試人員，也可以是PM。
代碼復審
我們切換到Reviewers界面。
此時，Reviewers若對代碼不滿，可以在對應的代碼出標出，讓開發人員繼續修改。若沒有問題，且出現圖中綠色的畫面（和基礎分支不沖突），則可以進行Merge。
恭喜！這樣代碼就Merge完成了。一般情況下，需要刪掉PR所創建的開發分支。
另外，如果Merge過程中出現沖突，如多個PR修改了同一份文件，GitHub還提供網頁版編輯器供Reviewer去選擇應該保留哪些、不保留哪些。
以上就是開發者進行源代碼修改的整個過程。