在第一篇文章，我們有簡單說明 GitHub flow，下圖所示，主要的流程微 建立 Branch > 加入 Commit > 建立 Pull Request > Code Review > 合併前部署 > 合併。

其中，整個 GitHub flow 中最讓人津津樂道的功能就是Pull Request： Contributor 與 Owner 之間會有些有趣互動，像是：

1. Owner 審閱請求與程式碼 (可能要求程式修改符合需求與Coding Style)
2. Owner 可能拒絕請求 (不需要此功能或想法不一致)
3. Contributor 說明修正/提議的原因 (覺得這對專案有幫助)
4. Contributor 協助修正問題或新增功能 (讓人感到真棒!!)

在本篇文章，我們會將整個流程走過一次，讓您更清楚是如何運作。

整個流程最難的部分在於 code review，如何能正確指出程式碼中的問題與為什麼要這樣修改是需要學習與經驗累積的。許多資深技術能寫出一手好程式碼，但也難以正確的 Review 出別人的問題。

第一步：Create Branch
若你有閱讀前面的文章，我們在 GitHub Branch 策略 - 哪一種方式適合你? 這篇文章中有建立一個 FirstBranch，可以參考這篇文章建立分支。

第二步：Add Commit
我們切換到這個 FirstBranch，並隨意在任一檔案中修改文字，並進行 Commit。

剛剛完成推送程式碼後，回到 Repo 主畫面，上方有提示告知某個 Branch 已經更新，你是否需要 比對內容 & 建立 Pull Request。我們點選 Compare & pull request 按鈕。

第三步：Pull Request
Pull Request 的定義為向開源專案提交貢獻的方法，比較簡易的行為描述為：

1. 宣告推送一個分支
2. 與 Owner 討論變更變更內容
3. Owner 檢視變更內容
4. 加入更多 commit
5. 最後合併或拒絕

在 open pull request，首先要確認的是分支合併來源與目的是否正確，並確認沒有衝突可以合併 (下圖上方紅框框處
)；在右邊選單可以指派 Reviewer 與 Assignees，設定 Labels, Project, 與 Milestone；中間可以加入此 pull request 的描述

理所當然，越多的描述與設定可以讓 Owner 更了解你的目的，可以加速同意 pull request 進行 merge

第四步: Code Review
你可以看到所有的行為與討論都會在 Conversation 中被記錄，讓每個參與者可以清楚事情的來龍去脈

點開 Files Change 可以看見變更的內容，你可以在程式碼上面輸入評論或 Review，讓 Contributor 了解那些內容需要變更以符合需求。

第五步: 合併前部署
這部分我們待後面文章提到 GitHub Action 後再說明。

第六步: 合併

當 contributor 與 owner 一陣互動後，也修改了許多內容。Owner 確認沒問題，即可以 Conversion 最下方點選 Merge pull request，輸入相關內容後點選 confirm merge 進行合併

後續系統會回覆是否要刪除這個 branch

建議如果沒有特殊情況，可以刪除該 branch 避免越來越多

最後，你可以回到該 Repo > Pull Request 畫面中 Close 的頁簽找到這個關閉的 pull request，也能檢視主要分支 (Main) 是否已經完成修改。

閱讀完本篇文章，你應該對於 Github flow 與 pull reqeust 已經不陌生。許多的 DevOps 工具也內建 open pull request 功能讓團隊成員可以進行 code review，除了檢視沒有惡意程式碼外，也確保了專案的品質。

若你喜歡我的文章，歡迎分享與訂閱。