Open XXHolic opened 4 years ago
这是 Git branching model 之后的第二篇资料。
GitHub 流是一个轻量的、基于分支的工作流，它支持定期进行部署的团队和项目。原文见 Understanding the GitHub flow。下面是整体示意图。
当你在做一个项目的时候，你会在任何时候有一堆不同的特性或想法在进行中，有些已经准备好了，有些还没有。分支帮助你管理此工作流。
当你在项目中创建一个分支时，你是在创建一个可以尝试新想法的环境。你做的变更不会影响 master 分支，因此你可以自由的实验和提交变更，这是安全的，因为在你的分支准备好给某些人审阅之前不会被合并。
master
分支在 Git 是一个核心的概念，整个 GitHub 工作流都是基于这概念。这里只有一条规则：master 分支的任何内容总是可部署的。
由于这个规则，如果你是基于 master 创建的功能或修复分支，你分支的名称应该语义化，例如 refactor-authentication, user-content-cache-key, make-retina-avatars ，这样其他人就可以明白分支正在做什么。
refactor-authentication
user-content-cache-key
make-retina-avatars
创建分支后，就可以开始进行更改了。无论何时添加、编辑或删除文件，都会进行提交，并将其添加到分支中。添加提交的过程会在功能分支上跟踪你的进度。
提交还创建了一个透明的工作历史，其他人可以根据它来理解你所做的事情和原因。每个提交都有一个关联的提交信息，这是一个说明，解释为什么进行了特定更改。此外，每个提交都被视为独立的变更单元。如果发现 bug，或者决定转向不同的方向，则可以回滚更改。
提交消息很重要，特别是因为 Git 跟踪你的更改，并在将更改推送到服务器后将其显示为提交。通过编写明确的提交消息，可以使其他人更容易地跟进并提供反馈。
Pull Request 发起关于提交的讨论。因为它们与底层 Git 存储库紧密集成，所以如果他们接受你的请求，任何人都可以确切看到会合并哪些更改。
Pull Request
在开发过程中的任何时候，你都可以发起 Pull Request ：当你有少量或没有代码，但希望共享一些屏幕截图或一般想法时，当你陷入困境并需要帮助或建议时，或者当你准备好让别人检查你的工作时。通过在 Pull Request 中使用 GitHub 的 @ 系统，你可以请求特定人员或团队的反馈，无论他们是在大厅下面还是十个时区之外。
@
Pull Request 对于参与开源项目和管理共享库的更改非常有用。如果你使用 Fork & Pull 模式，Pull Request 提供了一种方法，通知项目维护人员关于你希望他们考虑的更改。如果你使用的是共享库模式，则在将请求合并到主分支之前，Pull Request 有助于启动对更改的代码审阅和讨论。
Fork & Pull
发起 Pull Request 后，审阅更改的人员或团队可能会有问题或评论。可能是编码风格与项目规范不符，更改缺少单元测试，或者一切看起来都很好，支撑也很整齐。Pull Request 旨在鼓励和记录此类对话
你还可以根据对提交的讨论和反馈继续推进到分支。如果有人评论说你忘记做某事，或者代码中有错误，你可以在你的分支中修复它并提交更改。GitHub 将在同一个 Pull Request 中显示你的新提交以及可能收到的任何其它反馈。
使用 GitHub ，可以在合并到 master 之前，从一个分支部署已进行最终的生产测试。
一旦审查了 Pull Request 并且分支通过了测试，就可以部署更改以在生产中验证它们。如果你的分支导致问题，可以通过将现有 master 部署到生产环境中来回滚它。
现在你的更改已经在生产环境中得到验证，现在是将代码合并到 master 的时候了。
合并后，Pull Request 将保留对代码的历史更改的记录。因为它们是可搜索的，它们让任何人都能及时回顾，明白为什么以及如何做出这些决定的。
目录
引子
这是 Git branching model 之后的第二篇资料。
简介
GitHub 流是一个轻量的、基于分支的工作流，它支持定期进行部署的团队和项目。原文见 Understanding the GitHub flow。下面是整体示意图。
创建分支
当你在做一个项目的时候，你会在任何时候有一堆不同的特性或想法在进行中，有些已经准备好了，有些还没有。分支帮助你管理此工作流。
当你在项目中创建一个分支时，你是在创建一个可以尝试新想法的环境。你做的变更不会影响
master分支，因此你可以自由的实验和提交变更，这是安全的，因为在你的分支准备好给某些人审阅之前不会被合并。提示
分支在 Git 是一个核心的概念，整个 GitHub 工作流都是基于这概念。这里只有一条规则：master 分支的任何内容总是可部署的。
由于这个规则，如果你是基于
master创建的功能或修复分支，你分支的名称应该语义化，例如refactor-authentication,user-content-cache-key,make-retina-avatars，这样其他人就可以明白分支正在做什么。添加提交
创建分支后，就可以开始进行更改了。无论何时添加、编辑或删除文件，都会进行提交，并将其添加到分支中。添加提交的过程会在功能分支上跟踪你的进度。
提交还创建了一个透明的工作历史，其他人可以根据它来理解你所做的事情和原因。每个提交都有一个关联的提交信息，这是一个说明，解释为什么进行了特定更改。此外，每个提交都被视为独立的变更单元。如果发现 bug，或者决定转向不同的方向，则可以回滚更改。
提示
提交消息很重要，特别是因为 Git 跟踪你的更改，并在将更改推送到服务器后将其显示为提交。通过编写明确的提交消息，可以使其他人更容易地跟进并提供反馈。
发起 Pull Request
Pull Request发起关于提交的讨论。因为它们与底层 Git 存储库紧密集成，所以如果他们接受你的请求，任何人都可以确切看到会合并哪些更改。在开发过程中的任何时候，你都可以发起
Pull Request：当你有少量或没有代码，但希望共享一些屏幕截图或一般想法时，当你陷入困境并需要帮助或建议时，或者当你准备好让别人检查你的工作时。通过在Pull Request中使用 GitHub 的@系统，你可以请求特定人员或团队的反馈，无论他们是在大厅下面还是十个时区之外。提示
Pull Request对于参与开源项目和管理共享库的更改非常有用。如果你使用Fork & Pull模式，Pull Request提供了一种方法，通知项目维护人员关于你希望他们考虑的更改。如果你使用的是共享库模式，则在将请求合并到主分支之前，Pull Request有助于启动对更改的代码审阅和讨论。讨论和审阅
发起
Pull Request后，审阅更改的人员或团队可能会有问题或评论。可能是编码风格与项目规范不符，更改缺少单元测试，或者一切看起来都很好，支撑也很整齐。Pull Request旨在鼓励和记录此类对话你还可以根据对提交的讨论和反馈继续推进到分支。如果有人评论说你忘记做某事，或者代码中有错误，你可以在你的分支中修复它并提交更改。GitHub 将在同一个
Pull Request中显示你的新提交以及可能收到的任何其它反馈。发布
使用 GitHub ，可以在合并到
master之前，从一个分支部署已进行最终的生产测试。一旦审查了
Pull Request并且分支通过了测试，就可以部署更改以在生产中验证它们。如果你的分支导致问题，可以通过将现有master部署到生产环境中来回滚它。合并
现在你的更改已经在生产环境中得到验证，现在是将代码合并到
master的时候了。合并后，
Pull Request将保留对代码的历史更改的记录。因为它们是可搜索的，它们让任何人都能及时回顾，明白为什么以及如何做出这些决定的。参考资料
:wastebasket:
> 人并不是活在国家里，而是活在这个国家的语言里。 ![69-poster][url-local-poster]