共计 1854 个字符，预计需要花费 5 分钟才能阅读完成。
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 号议题。无关更多信息，请查看咱们的帮忙文章。
