GitHub Flow 工作流程、知识要点

1. GitHub Flow 工作流程

GitHub Flow 是一个轻量级的、基于分支的工作流，这对于有定期部署的团队和项目非常有用，下面将介绍如何使用与为何使用 GitHub Flow 。

1.1 创建分支（Create a branch）

• When you’re working on a project, you’re going to have a bunch of different features or ideas in progress at any given time – some of which are ready to go, and others which are not. Branching exists to help you manage this workflow.
  当您在进行项目时，在任何给定时间都会有许多不同的功能或想法在进行中-其中一些已准备就绪，而另一些则没有。 存在分支可帮助您管理此工作流程。

• When you create a branch in your project, you’re creating an environment where you can try out new ideas. Changes you make on a branch don’t affect the main branch, so you’re free to experiment and commit changes, safe in the knowledge that your branch won’t be merged until it’s ready to be reviewed by someone you’re collaborating with.
  当您在项目中创建分支时，就是在创建一个可以尝试新想法的环境。 您在分支机构上所做的更改不会影响主分支机构，因此您可以自由地尝试并提交更改，因为您知道分支机构不会被合并，直到准备好与您的合作者进行审查，您才能自由地进行合并 。

• ProTip
  Branching is a core concept in Git, and the entire GitHub flow is based upon it. There’s only one rule: anything in the main branch is always deployable.
  分支是Git中的核心概念，整个GitHub流程都以此为基础。 只有一条规则：main分支中的任何内容始终都是可部署的。

  Because of this, it’s extremely important that your new branch is created off of main when working on a feature or a fix. Your branch name should be descriptive (e.g., refactor-authentication, user-content-cache-key, make-retina-avatars), so that others can see what is being worked on.
  因此，在处理功能或修订时，要从main之外创建新分支是非常重要的。 您的分支名称应该是描述性的（例如，refactor-authentication, user-content-cache-key, make-retina-avatars），以便其他人可以看到正在处理的内容。

1.2 添加提交（Add commits）

• Once your branch has been created, it’s time to start making changes. Whenever you add, edit, or delete a file, you’re making a commit, and adding them to your branch. This process of adding commits keeps track of your progress as you work on a feature branch.
  创建分支后，就该开始进行更改了。 无论何时添加，编辑或删除文件，都在进行提交，并将其添加到分支中。 添加提交的过程会跟踪您在功能分支上工作的进度。

• Commits also create a transparent history of your work that others can follow to understand what you’ve done and why. Each commit has an associated commit message, which is a description explaining why a particular change was made. Furthermore, each commit is considered a separate unit of change. This lets you roll back changes if a bug is found, or if you decide to head in a different direction.
  提交还会为您的工作创建一个透明的历史记录，其他人可以遵循该历史记录来了解您的工作以及原因。 每个提交都有一个关联的提交消息，该消息是说明为什么进行特定更改的说明。 此外，每次提交都被视为一个单独的变更单元。 如果发现错误或决定朝其他方向前进，则可以回滚更改。

• ProTip
  Commit messages are important, especially since Git tracks your changes and then displays them as commits once they’re pushed to the server. By writing clear commit messages, you can make it easier for other people to follow along and provide feedback.
  提交消息很重要，尤其是因为Git会跟踪您的更改，然后将它们显示为提交后将其显示在服务器上。 通过编写清晰的提交消息，您可以使其他人更容易跟进并提供反馈。

1.3 开启拉取请求（Open a Pull Request）

• Pull Requests initiate discussion about your commits. Because they’re tightly integrated with the underlying Git repository, anyone can see exactly what changes would be merged if they accept your request.
  拉取请求引发有关提交的讨论。 由于它们与基础Git存储库紧密集成，因此任何人都可以确切地看到如果接受您的请求将合并哪些更改。

• You can open a Pull Request at any point during the development process: when you have little or no code but want to share some screenshots or general ideas, when you’re stuck and need help or advice, or when you’re ready for someone to review your work. By using GitHub’s @mention system in your Pull Request message, you can ask for feedback from specific people or teams, whether they’re down the hall or ten time zones away.
  您可以在开发过程中的任何时候打开“拉取请求”：当您几乎没有代码或只想共享一些屏幕截图或一般性想法时，遇到困难并需要帮助或建议时，或者准备就绪时 有人来审查您的工作。 通过在Pull Request消息中使用GitHub的@mention系统，您可以要求特定人员或团队提供反馈，无论他们是在大厅还是十个时区之外。

• ProTip
  Pull Requests are useful for contributing to open source projects and for managing changes to shared repositories. If you’re using a Fork & Pull Model, Pull Requests provide a way to notify project maintainers about the changes you’d like them to consider. If you’re using a Shared Repository Model, Pull Requests help start code review and conversation about proposed changes before they’re merged into the main branch.
  拉取请求对于贡献于开源项目和管理共享存储库的更改很有用。 如果您使用的是Fork＆Pull模型，Pull Requests提供了一种方法，可以将您希望他们考虑的更改通知项目维护人员。 如果您使用的是共享存储库模型，则“拉取请求”可在合并到主分支之前帮助您开始代码审查和有关建议更改的对话。

1.4 讨论并审阅代码（Discuss and review your code）

• Once a Pull Request has been opened, the person or team reviewing your changes may have questions or comments. Perhaps the coding style doesn’t match project guidelines, the change is missing unit tests, or maybe everything looks great and props are in order. Pull Requests are designed to encourage and capture this type of conversation.
  打开“拉取请求”后，审阅您的更改的人员或团队可能会有疑问或意见。 可能是编码风格与项目准则不符，更改缺少单元测试，或者看起来一切都很好并且道具井井有条。 提取请求旨在鼓励和捕获这种类型的对话。

• You can also continue to push to your branch in light of discussion and feedback about your commits. If someone comments that you forgot to do something or if there is a bug in the code, you can fix it in your branch and push up the change. GitHub will show your new commits and any additional feedback you may receive in the unified Pull Request view.
  您还可以根据有关提交的讨论和反馈继续推送到分支机构。 如果有人评论您忘记做某事，或者代码中有错误，则可以在分支机构中对其进行修复，然后进行更改。 GitHub将在统一的“拉取请求”视图中显示您的新提交以及您可能收到的任何其他反馈。

• ProTip
  Pull Request comments are written in Markdown, so you can embed images and emoji, use pre-formatted text blocks, and other lightweight formatting.
  拉取请求注释是用Markdown编写的，因此您可以嵌入图像和表情符号，使用预格式化的文本块以及其他轻量级格式。

1.5 部署（Deploy）

• With GitHub, you can deploy from a branch for final testing in production before merging to main.
  使用GitHub，您可以从分支机构进行部署，以便在合并到main之前进行生产中的最终测试。

• Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production. If your branch causes issues, you can roll it back by deploying the existing main branch into production.
  在审核您的拉取请求并且分支机构通过了测试之后，您可以部署更改以在生产中进行验证。 如果分支机构引起问题，则可以通过将现有的主分支部署到生产中来回滚。

• Different teams may have different deployment strategies. For some, it may be best to deploy to a specially provisioned testing environment. For others, deploying directly to production may be the better choice based on the other elements in their workflow.
  不同的团队可能有不同的部署策略。 对于某些人来说，最好将其部署到专门配置的测试环境中。 对于其他人，基于工作流中的其他元素，直接部署到生产可能是更好的选择。

1.6 合并（Merge）

• Now that your changes have been verified in production, it is time to merge your code into the main branch.
  现在您的更改已在生产环境中得到验证，是时候将您的代码合并到主分支中了。

• Once merged, Pull Requests preserve a record of the historical changes to your code. Because they’re searchable, they let anyone go back in time to understand why and how a decision was made.
  合并后，拉取请求会保留代码历史更改的记录。 因为它们是可搜索的，所以它们使任何人都能及时返回，以了解做出决定的原因和方式。

• ProTip
  By incorporating certain keywords into the text of your Pull Request, you can associate issues with code. When your Pull Request is merged, the related issues are also closed. For example, entering the phrase Closes #32 would close issue number 32 in the repository.
  通过将某些关键字合并到“拉取请求”的文本中，可以将问题与代码关联。 合并您的请求请求后，相关问题也将关闭。 例如，输入短语“关闭＃32”将关闭存储库中的问题编号32。