GitHub 轻量级工作流程 - Github flow 与 Pull request

在第一篇文章，我们有简单说明 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，除了检视没有恶意程序码外，也确保了专案的品质。

若你喜欢我的文章，欢迎分享与订阅。