GitHub 翻译之 https://guides.github.com/introduction/flow/ 翻译(GitHub 工作流翻译)

Understanding the GitHub Flow
GitHub Flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly. This guide explains how and why GitHub Flow works.
GitHub 工作流是一个轻量级的、基于分支理论的工作流方法，它为团队和那些需要定期进行部署的工程项目提供支持。这个指南解释GitHub工作流的流程以及这样设计的原因。

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 master 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.
当你在你的项目中创建了一个分支版本时候，你也就创造了一个尝试你的好想法的环境。在分支版本上对代码做出的修改不会影响到你的master （主程序）程序，因此你可以自由的尝试修改和提交代码，直到与你合作的工程师决定根据你的修改修订主程序代码。

ProTip
Branching is a code concept in Git, and the entire GitHub Flow is based upon it.
There’s only one rule: anything in the master branch is always deployable.
专业小贴士： 版本分支是Git上的一个核心概念。整个GitHub 工作流都基于此。
只有一条准则：在master分支上的程序都可以被复制为多个分支程序。

Because of this , it’s extremely import that your new branch is created off of master 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.
因为这个原因，当你在开发一个新功能或者处理一个问题的时候从主程序中创建一个分支版本是非常重要的。你的分支版本名称最好起一个容易易懂、体现你修改内容的名称(例如：refactor-authentication ,user-content-cache-key,make-retina-avatars) ，这样别人才能够快速地知道你提交的是什么。

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.
后台程序会记录下你的修改过程，并公开这些修改，以便别人能够知道你修改了什么，进一步理解你为什么这样修改。你的每一次提交都会有一个关联的提交描述信息，记录着你为什么要修改这一块代码。此外，每个提交都被认作是一个独立的修改单元（不会影响到其他版本)。这样当你发现一个bug 或者有不同的想法的时候可以回退。

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系统会跟踪你的修改，并把它们展示给其他人。通过提交清晰的修改备注信息，别人会很容易明白你修改的内容并很快给出回复。

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.
针对你的提交信息， Pull Request 会发起一个讨论。因为你提交的修改后的代码和备注说明会与Git 代码库紧紧地结合起来，所以有人接受了你的Pull Request 请求后，他们会看到你修改了什么，以及哪些需要合并到主程序中。

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 （在你 Pull Request 窗口中）你可以向特定人或者团队寻求回复。

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 master branch.
专业小贴士：对于打开一个代码资源库，或者修改分享代码资源来说，Pull Requests 都非常有用。如果你在使用 Fork & Pull Model ，Pull Requests 会为你提供一个通知项目维护人员考虑你的修改的方式。如果你在使用 Shared Repository Model ，Pull Requests 会在代码合并到master 中之前帮助你与他人进行关于要修改的代码的讨论。

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.
一旦你打开了一个 Pull Request，代码修订人员或团队会有很多问题和评论。也许代码风格不符合项目规定的格式，也许修改的代码没有单元测试，或者一切看起来都是如此的完美。Pull Request 的设计原则就是用来鼓励和引导这类讨论的。

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.
你也可以小范围的讨论和反馈来推动整个流程的进度。如果有人评论你忘了一些事情或者代码中有bug,你可以在你的分支中处理它并把结果提交到服务器上。GitHub 会在统一的Pull Request 页面展示你最新提交的内容和别人最新的反馈信息。

ProTip
专业小贴士
Pull Request comments are written in Markdown, so you can embed images and emoji, use pre-formatted text blocks, and other lightweight formatting.
Pull Request 评论是用Markdown 工具编辑的，因此你可以插入图片和表情图标，用格式化的文本进行编辑。

Deploy(项目部署)

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 master into production.
一旦你的Pull Request 通过了审核，并且分支版本的代码也通过了你的测试，你就可以把你修改的代码放到生产上进行验证。如果修改的代码在生产上验证的时候有问题，你可以通过把上一个 master （上一个生产版本）重新部署到生产上以此来实现回退。

Merge(项目代码合并)

Now that your changes have been verified in production, it is time to merge your code into the master branch.
如果你修改的代码在生产上已经通过了验证，那么现在就要把你修改的代码整合到master 分支中（主分支中）。

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.
一旦合并，Pull Request 会在你的代码中保存一个历史修改记录。因为这些都是可以被搜索到的，所以它可以是任何人随时查看和了解当初是如何决定修改的。

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. For more information, check out our help article.
通过向你的Pull Request中合并某些关键词，你可以把问题和代码关联起来。当你的Pull Request 合并以后，那些关联的问题也会被关闭。例如：输入短语Closes #32 将会把代码库中32号问题关闭。要了解更多信息请查看帮助文档。