面向（React）开发者的专业 Git 工作流程和 GitHub 设置（含屏幕录像）
由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！
如果你是一名独立开发者，从事自己的项目，那么你的 Git 工作流程通常很简单：你每天都在主分支（或 master 分支）上工作。
你可能知道，专业的开发团队不会这样工作。多个开发人员同时向主分支提交代码很快就会变得混乱。而且，未经审查或测试的代码最终很可能会被部署到生产环境中。危险！
专业团队会使用流程和工作流来防止这种情况发生。而开发团队中最常用的 Git 工作流（至少根据我的经验）是：
基于主干的开发（或者更准确地说，是基于规模化的主干的开发）。
如果你想成为一名专业开发人员，我强烈建议你提前熟悉这种工作流程。你越了解专业人士的工作方式，你的第一份工作就越不容易让你感到不知所措。
我保证：如果你掌握了 Git 的基础知识，它并不难。但是围绕 Git 有很多术语，一开始可能会让你感到困惑。
观看下方视频，了解我如何演示工作流程的一个周期。视频下方提供了如何在 GitHub 仓库中设置分支保护以强制执行此工作流程的说明，以及基于屏幕截图的详细演练。
本系列文章和我正在开发的应用程序是我即将推出的 React 工作模拟器的一部分。像专业团队一样亲自动手构建项目，获得真实的工作经验。
目录
主干式开发简述
- 你从主分支检出一个新分支。
- 你将代码提交到这个分支，并将其推送到 GitHub 仓库。
- 你提交一个拉取请求（或者像 GitLab 所称的合并请求）。
- 自动化测试验证应用程序是否按预期运行。
- 队友会审查你的代码，你根据反馈进行调整。
- 您可以通过拉取请求（简称 PR）将您的分支合并到主分支中。
如果这些听起来像天书，别担心。看看我的免费课程，你可以在那里学习和练习这种工作流程。
Pull Request到底是什么？
我一直觉得 GitHub 上的 Pull Request 这个名字很让人困惑。GitLab 称之为 Merge Request，这个名字更贴切。简单来说，Pull Request 就是一种请求将你的代码合并到主分支的权限的方式：
“嘿，团队成员们，谁能帮我看一下这段代码，看看它是否可行？我想把它合并到主分支上，这样我们的用户就能从中受益。”
你可以把 Pull Request 看作是 Git 分支上的一个功能，它允许你从团队成员那里获得反馈。正如前面提到的，它还允许你在代码更改提交到主分支之前自动运行检查和测试。
总而言之，Pull Requests 是
- 一种收集反馈从而提高代码质量的机制
- 一款用于对代码运行自动化（例如测试）的工具，以降低将错误引入生产代码的风险。
分支保护：强制使用拉取请求
流程和工作流固然重要，但人们总是懒惰，喜欢寻找变通方法。因此，理想情况下，我们希望强制团队中的每个人都使用 Pull Request，而不是直接提交到主分支。
幸运的是，GitHub 提供了一项名为“分支保护”的功能来保护我们的主分支。要保护主分支，请打开 GitHub 上的仓库设置，在左侧菜单中选择“分支”，然后单击“添加规则”按钮。
关于所选规则的几点说明：
- 在开发团队中，“合并前需要提交 Pull Request”→“需要审批”选项通常会被启用。这样可以强制开发人员互相审查和批准代码。这既能有效防止新 bug 的出现，又能提高代码质量和一致性。
- “要求线性历史记录”选项并非必需，但根据我的经验，现在很多团队都使用它。它会阻止在相应分支上进行合并提交。相反，您必须“压缩并合并”拉取请求或“变基”。您可以在此视频中看到“压缩并合并”的实际操作演示及相关说明。
- 如果您希望在自己的代码库中强制执行工作流程，“包含管理员”选项非常重要。否则，由于您是管理员，这些规则将对您无效。
如果开发人员现在在主分支上创建一个提交并尝试推送，他们会看到一条错误消息。
主干开发工作流程概览
提交拉取请求
git checkout -b migrate-to-styled-components
现在我们编写代码，提交并将其推送到 GitHub 上的远程存储库。
git commit -m "Migrate home page to styled-components"
git push origin migrate-to-styled-components
现在，您应该可以在 GitHub 上看到一个创建 Pull Request 的横幅。
点击按钮后，你会看到一个表单，可以在其中输入标题和描述。接下来，点击“创建拉取请求”按钮。
恭喜，您已提交了第一个 Pull Request！现在您应该看到以下内容：
持续集成管道
你注意到PR底部的状态检查了吗？
这是一个非常实用的功能。你可以在 Pull Request 中运行类似 ` npm run dev`npm run lint这样的脚本npm run test，以降低引入 bug 的风险。这叫做持续集成流水线。明天文章会详细介绍，就先卖个关子吧。如果你等不及，可以先看看视频，了解我的设置过程。
代码审查
在实际的团队协作中，你的代码通常至少会由一位队友进行审查。这有助于预防 bug，并保持代码库的整洁和一致性。如果你遇到问题，提交 Pull Request 也是一个很好的讨论方式。
现在我们切换到另一个有代码仓库访问权限的账号。以下是我们假想的队友会如何审查你的代码。
我们的队友可以为代码添加注释。
最后，他们提交了评审报告。
作为 Pull Request 的作者，我们现在可以看到评论了。
处理评论
我们现在有两个选择：我们可以根据评论更新代码，或者发起讨论。
要调整代码，我们只需回到本地机器，修改代码，提交并推送即可。您可以在代码审查评论下方看到新的提交。您也可以添加评论来解决问题。
最后，您可以申请新的审核：
批准拉取请求
当你的队友满意后，他们可以通过提交审核来批准你的拉取请求。他们可能会添加一些无用但表示肯定的表情符号评论来让你高兴。
合并拉取请求
最后，是时候合并我们的拉取请求了。现在我们的代码更改将被添加到主分支中。
还记得我们在分支保护规则中设置了“需要线性历史记录”选项吗？这就是为什么默认情况下我们看到的是“压缩并合并”按钮，而不是简单的“合并”按钮。
我们来看看按下按钮后会发生什么：
按下确认按钮后，一切就绪。
主分支的历史
我还没解释“合并”按钮的作用，对吧？拉取请求（或我们的 Git 分支）包含多个提交：
当我们查看主分支的提交历史时，发现这些提交都不见了。取而代之的是，只有一个提交指向了拉取请求（通过链接#6）：
我们原始分支的所有提交都已合并为一个提交。这样做的好处是，您无需在拉取请求中保持提交记录的整洁。例如，在代码审查过程中进行的简单修复，例如“移除未使用的类名”，实际上无需出现在主分支的提交历史记录中。
正在更新本地主分支
最后一步（很容易忘记）是将本地主分支与远程仓库同步。由于合并操作发生在 GitHub 上，我们的本地机器还不知道主分支上的这些更改。
git pull origin main
当我们在开发团队中工作时，每次开始处理新分支时，我们都应该这样做。
概括
本文介绍了如何设置带有分支保护的 GitHub 仓库，以强制执行一种名为“主干开发”的常用 Git 工作流程。希望通过这篇详细的教程，您现在对 Git 和 GitHub 不再感到畏惧。
