GitHub flow工作流

github.com

github.com使用自己版本的标记语法，它提供了一组额外的有用的

特性，其中许多特性使处理github.com上的内容更加容易。

用户名-提及

键入一个@符号，后跟一个用户名，将通知此人前来查看评论。

这叫做“提及”，因为你提到的是个人。你也可以提到组织内的团队。

围栏代码块

markdown将带有四个前导空格的文本转换为一个代码块；使用gfm，您可以用``来包装代码，从而创建一个没有

领先的空间。添加可选的语言标识符和带有get语法突出显示的代码。

Issue引用

任何涉及问题或请求的数字都将自动转换为链接。

-[X]这是一个完整的项目

-[]这是一个不完整的项目

-[X]@引用，引用，[链接]（），**格式化**，支持<del>标记

-[X]需要列表语法（支持任何无序或有序列表）

表

可以通过组合单词列表并用连字符分隔来创建表（对于第一行）。

然后用一根管子把每根柱子分开：

要查看每个支持图像的列表，请查看

www.emoji-cheat-sheet.com网站

Github支持表情符号！

GitHub flow

GitHub flow是一个轻量级的，基于分支的工作流，它非常适合项目部署频繁的团队使用。

创建一个分支

当您在进行项目时，在任何给定的时间都会有许多不同的功能或想法在进行中-其中一些已经准备就绪，而另一些则没有。存在分支可帮助您管理此工作流程。

当您在项目中创建分支时，您正在创建一个可以尝试新想法的环境。您在分支机构上所做的更改不会影响master分支机构，因此您可以自由地尝试并提交更改，因为您可以知道自己的分支机构不会被合并，直到准备好与您的协作者进行审查为止，这是安全的。

专家提示

分支是Git中的核心概念，整个GitHub流程都以此为基础。只有一条规则：master分支中的任何内容始终都是可部署的。

因此，在处理功能或修订时，要在主分支之外创建新分支非常重要。您的分行名称应该是描述性的（如refactor-authentication，user-content-cache-key，make-retina-avatars），以便其他人可以看到正在开发中。

添加提交

创建分支后，就可以开始进行更改了。无论何时添加，编辑或删除文件，都在进行提交，并将其添加到分支中。添加提交的过程可以跟踪您在功能分支上工作的进度。

提交还会为您的工作创建一个透明的历史记录，其他人可以遵循该历史记录来了解您的工作以及原因。每个提交都有一个关联的提交消息，该消息是说明为什么进行特定更改的说明。此外，每次提交都被视为一个单独的更改单元。如果发现错误或决定朝其他方向前进，则可以回滚更改。

专家提示

提交消息非常重要，尤其是因为Git会跟踪您的更改，然后将它们显示为提交后将其显示在服务器上。通过编写清晰的提交消息，您可以使其他人更容易跟进并提供反馈。

打开拉取请求

拉取请求引发有关提交的讨论。由于它们与基础Git存储库紧密集成，因此任何人都可以确切地看到如果接受您的请求将合并哪些更改。

您可以在开发过程中的任何时候打开“拉取请求”：当您很少或没有代码，但想共享一些屏幕截图或一般性想法时，遇到困难需要帮助或建议时，或者准备为某人准备时查看您的工作。通过在Pull Request消息中使用GitHub的@mention系统，您可以要求特定人员或团队提供反馈，无论他们是在大厅内还是在十个时区之外。

专家提示

拉取请求对于贡献于开源项目和管理共享存储库的更改很有用。如果您使用的是Fork＆Pull模型，则Pull Requests提供了一种方法，可以将您希望他们考虑的更改通知项目维护人员。如果您使用的是共享存储库模型，则“拉取请求”可在合并到master分支之前帮助您开始代码审查和有关建议更改的对话。

讨论并检查您的代码

打开“拉取请求”后，审阅您所做更改的人员或团队可能会有疑问或意见。也许编码风格与项目准则不匹配，更改缺少单元测试，或者一切看起来都很不错，并且道具井井有条。提取请求旨在鼓励和捕获这种类型的对话。

您还可以根据有关提交的讨论和反馈继续推送到分支机构。如果有人评论您忘记做某事，或者代码中有错误，则可以在分支机构中对其进行修复，然后进行更改。GitHub将在统一的“拉取请求”视图中显示您的新提交以及您可能收到的任何其他反馈。

专家提示

拉取请求注释是用Markdown编写的，因此您可以嵌入图像和表情符号，使用预格式化的文本块以及其他轻量级格式。

部署

使用GitHub，您可以从分支机构进行部署，以在正式合并之前进行生产中的最终测试。

审核拉取请求并且分支机构通过测试后，您可以部署更改以在生产中进行验证。如果分支机构引起问题，则可以通过将现有的主服务器部署到生产中来回滚它。

合并

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

合并后，拉取请求会保留代码历史更改的记录。因为它们是可搜索的，所以它们使任何人都可以及时返回以了解做出决定的原因和方式。

专家提示

通过将某些关键字合并到“拉取请求”的文本中，可以将问题与代码关联。合并您的请求请求后，相关问题也将关闭。例如，输入短语Closes #32将关闭存储库中的问题编号32。有关更多信息，请查看我们的帮助文章。