【翻译】了解 Github 工作流

GitHub 工作流是一个轻量级的、基于分支的工作流，支持实行定期进行部署计划的团队和项目。本指南解释了 GitHub 工作流的工作方式和原因。

创建一个分支

当你在做一个项目的时候，你会有一堆不同的功能或想法，它们可能出现在任何时候——有些已经准备好了，有些还没有。分支的存在可以帮助您管理此工作流。

当您在项目中创建分支时，您正在创建一个可以尝试新想法的环境。您对分支所做的更改不会影响 main 分支，因此您可以自由地进行实验并提交更改，因为您的分支不会被合并，直到它准备好供您的合作伙伴审阅。

建议：

分支是 Git 的核心概念，整个 GitHub 工作流都基于它。只有一条规则：主分支中的任何内容都是可部署的。

因此，在处理功能或修复时，在 main 之外创建新分支是非常重要的。你的分支名称应该是描述性的（例如：refactor-authentication、user-content-cache-key 或者是 make-retina-avatars），以便其他人看到正在进行的工作。

提交变更

创建分支后就可以开始进行更改了。无论何时添加、编辑或删除文件，都会在提交到分支中。提交变更的这个过程可以在处理功能分支时跟踪您的进度。

提交还可以创建一个透明的工作历史（Commit History），让其他人可以了解你做了什么以及为什么这么做。每个提交都有一个关联的提交消息（Commit Message），它可以说明为什么要进行特定更改。此外，每个提交都被视为一个单独的更改单元。如果发现了 bug 或者决定转向另一个方向，这可以让您回滚更改。

建议：

提交消息很重要，特别是因为 Git 跟踪您的更改，然后在将更改推送到服务器后将其展示。通过编写清晰的提交消息，您可以让其他人更容易跟进并提供反馈。

打开拉取请求

Pull Request 会启动关于您的提交的讨论。因为它们与底层 Git 存储库紧密集成，所以任何人都可以看到如果他们接受您的请求，将会合并哪些更改。

您可以在开发过程中的任何时候打开 Pull Request：当您几乎没有代码但想要共享一些屏幕截图或一般想法时、当您陷入困境需要帮助或建议时、或者当您准备好让别人审阅您的工作时。通过在 Pull Request 消息中使用GitHub 的 @ 提及系统，您可以请求特定人员或团队的反馈，无论他们 down the hall 还是十个时区之外。

建议：

Pull Request 对于开源项目和管理共享存储库的更改非常有用。如果您使用的是 Fork & Pull 模型，Pull Request 提供了一种通知项目维护人员关于您希望他们考虑的更改的方法。如果您使用的是共享存储库模型，那么 Pull Request 有助于在建议的更改合并到主分支之前启动代码检查和对话。

讨论并检查代码

打开 Pull Request 后，审阅您的更改的人员或团队可能会有问题或意见。也许编码风格与项目指南不匹配，更改缺少单元测试，或者一切看起来都很好。Pull Request 鼓励这种类型的交流。

您还可以根据有关您的提交的讨论和反馈继续向您的分支推进。如果有人说你忘了做什么，或者代码中有一个 bug，你可以在你的分支中修复它，并推送（Push）修改。GitHub 将在统一的 Pull Request 视图中显示您的新提交以及您可能收到的任何其他反馈。

建议：

Pull Request 的评论是用 Markdown 编写的，因此您可以嵌入图像和 emoji、使用预格式化的文本块和其他轻量级格式。

部署

使用 GitHub，您可以从分支进行部署，以便在合并（Merge）到主分支之前在生产环境中进行最终测试。

一旦您的 Pull Request 被审查且分支通过了您的测试，您就可以部署您的更改以在生产中验证它们。如果您的分支导致了问题，您可以通过将现有的主分支部署到生产中来回滚它。

不同的团队可能有不同的部署策略。对于一些人来说，最好是部署到一个专门配置的测试环境中。对于其他人来说，基于工作流中的其他元素，直接部署到生产环境可能是更好的选择。

合并

现在您的更改已经在生产中得到验证，现在是时候将代码合并到主分支中了。

合并后，Pull Request 将保留对代码的历史更改的记录。因此历史记录是可搜索的，任何人都能及时回到过去，了解为什么以及如何做出决定。

建议：

通过将某些关键字合并到 Pull Request 的文本中，可以将问题与代码关联起来。合并 Pull Request 时，也会关闭相关议题。例如，输入短语 Closes#32 将关闭存储库中的第 32 号议题。有关更多信息，请查看我们的帮助文章。