場景
假設有一個項目，要開發下一代的 Facebook，你就是這個項目的技術 leader，你的團隊有3個開發人員：
Alice：1年開發經驗
Bob：1年開發經驗
John：3年開發經驗
You：這個項目的技術 leader
Git 中的開發過程
Master branch 主分支
1）主分支始終包含線上產品的代碼。
2）任何人，包括技術 leader，都不允許直接修改主分支上的代碼，因爲主分支是線上代碼的拷貝。
3）代碼的開發是在其他分支上做的。
Release branch 發佈分支
1）項目啓動後，首先要爲項目創建一個 Release branch，是從 Master branch 創建出來的。
2）關於項目的所有代碼都會在這個 Release branch 中，這個 Release branch 也只是一個普通的分支，只是以 “release/” 開頭。
3）例如把我們這個項目的 Release branch 命名爲 “release/fb”。
4）可能同時會有多個項目在開發，所以，爲每個項目創建一個獨立的 Release branch，例如現在還有一個項目叫 “release/messenger”。
5）使用 Release branch 的目的就是多個項目間不影響。
Feature branch 特徵分支
1）開發每個功能時都創建一個 Feature branch，確保這個功能是單獨開發的。
2）Feature branch 是以 “feature/” 爲前綴名的普通分支。
3）你作爲技術leader，現在讓 Alice 去開發登錄功能，所以 Alice 創建了一個新的 Feature branch，叫做 “feature/login”，然後在這個分支中開發登錄功能。
4）Feature branch 通常是從 Release branch 中創建出來的。
5）你讓 Bob 開發加好友的功能，Bob 就創建了一個 Feature branch，命名爲 “feature/friendrequest”。
6）John 的任務是創建新聞 feed 流，他創建了 “feature/newsfeed”。
7）每個程序員都在自己的 Feature branch 中進行開發。
8）現在，Alice 的登錄功能開發完了，需要把自己 feature/login 分支中的代碼發到 release/fb 中，可以通過 pull request。
pull request
首先，不要把 pull request 和 git pull 混淆了。
開發人員不能直接把自己分支中的代碼推到 release branch 中。
技術 leader 先要做個 review，檢查一下代碼。
這就是通過 pull request 做的。
例如 GitHub 中的操作流程：
image
點擊 “New pull request” 後：
image
compare 是 Alice 自己的 feature/login 開發分支。
base 是項目的 release/fb 發佈分支。
之後，Alice 輸入一個標題和描述，最後點擊 “Create Pull Request”。
Alice 需要爲這個 pull request 分配一個 reviewer，就是你。
然後你就可以對 pull request 的代碼進行 review 了，沒問題後就可以把 feature/login 合併到 release/fb 了，此時 Alice 這個功能的代碼就算成功提交了。
代碼衝突
1）Bob 開發完了，也發起了一個 pull request，從 feature/friendrequest 到 release/fb。
2）因爲 release branch 已經有了 Alice 提交的登錄代碼，所以代碼衝突就發生了。你作爲技術leader，有責任去解決衝突，然後合併分支。
3）現在 John 開發完了，因爲 John 開發經驗比 Alice 和 Bob 都豐富，John 自己處理了代碼衝突。John 從 release/fb 拿到最新的代碼放到自己的 feature/newsfeed （通過 git pull 或 git merge），並處理了所有的衝突。
4）John 發起了一個 pull request，這時你就省心了，不用你來解決代碼衝突了。
所以，解決代碼衝突的2個途徑：
負責 pull request review 的人來處理。
開發人員自己處理，把最新的 release branch 合併到自己的 feature branch，解決掉所有代碼衝突。
回到 Master branch
項目開發完成後，release 分支合併回 master 分支。