GitHub（二）：理解GitHub流

客官°小女子只卖身不卖艺 2022-03-26 09:46 201阅读 0赞

# Understanding the GitHub flow #

原文链接 -> [传送门][Link 1]

GitHub 流是一个轻量级的、基于分支的工作流，它使得团队和项目的部署更有条不紊。

这一篇指导将解释 GitHub 流是如何工作的。

### **创建一个分支** ###

![160754qsi6iqyinti3twsh.jpg][]

你在开发某个项目的过程中，难免时不时会出现一连串新的想法——有些可以当时解决，有些则不能。分支的存在可以帮助你很好地控制这些工作流。

当你为你的项目创建一个分支时，你实际上创建的是一个允许你尝试新想法的环境。你在分支上做出的更改并不会影响到主分支，所以你可以自由地进行实验和提交更改，通过小伙伴们的代码审查之后，你就可以将其安全地合并到主分支上。

### **专业建议** ###

分支是 Git 的核心概念，整个 GitHub 流也是在基于分支的基础上建立的。记住只有一条规则：主分支上的任何东西总是可以被展开的。

因此，当你开发一个新功能或修复 bug 的时候，强烈建议你为此创建一个新分支。分支的名字应该是具有描述性的（比如 refactor-authentication, user-content-cache-key, make-retina-avatars），这样别人就可以很容易看出其工作内容。

### **添加提交** ###

![162839wsg5utkulxtucnxg.jpg][]

一旦你的分支创建完毕，就可以开始做一些更改了。每当你进行添加、编辑或删除一个文件时，都会提交并添加到你的分支里。当你在开发新功能的分支上工作时，添加提交的过程会跟踪你的工作进度。

提交同时还为你的工作创建了一个清晰的流程，这样别人就可以很容易理解你到底做了什么以及为何要这么做。每个提交都有相关联的提交信息，通常是用于描述“为什么进行这样的更改”。另外，每次提交都代表一次变化，这样你可以在发现bug或决定往其它方向开发时，回到之前变化的地方重新开始。

### **专业建议** ###

提交信息很重要，尤其是在 Git 跟踪了你的更改，并将他们提交到服务器并显示在小伙伴们的客户端时……如果有了明确的提交消息，就可以使得他们更容易理解你的想法并提供反馈。

### **发起 Pull Request** ###

![164414xfnftde1vyxyzyad.jpg][]

Pull Requests 将发起对你的提交的讨论，因为它们将与底层的 Git 仓库紧密集成，如果接受了你的请求，任何人都可以看到具体合并的是哪些更改。

在开发过程的任何时刻，你都可以发起 Pull Request：当你仅更改了少量代码（甚至都代码都没动过），但想要分享一些快照和思路的时候；当你的思路卡住了，需要一些帮助和建议的时候；或者当你准备让其他小伙伴来帮你审查代码的时候。在你的 Pull Request 信息中，使用 GitHub 的 @ 提醒系统可以从指定的人或团队那里获得反馈。

### **专业建议** ###

Pull Requests 不仅有助于开源项目的开发，也使得共享仓库的改动管理更加轻松。如果你使用分支推送模式（Fork & Pull Model），通过 Pull Requests，你可以将自己的更改建议通知给项目维护者；如果你使用共享仓库模式（Shared Repository Model），在改动被纳入主分支之前，Pull Requests 也方便了彼此之间的代码审查和改动内容的交流。

### **讨论和审查你的代码** ###

![233122ps7lcba0vwa6nkqq.jpg][]

当你提交一个 Pull Request，审查的人员或团队可能对你的更改有所疑问或意见……有可能是代码风格不符合项目规范，或者提交的更改缺乏单元测试，也可能所有内容都符合项目的要求。Pull Requests 就是被设计用于鼓励和记录这类型的交流。

你还可以根据有关你的提交的讨论和反馈，继续推送到你的分支。如果有人评论你忘记做某事或代码中存在 bug，你可以在你的分支中修复它并推送更改。GitHub 将在 Pull Request 视图中统一显示你的提交以及任何追加的反馈。

### **专业建议** ###

Pull Request 评论是使用 Markdown 来写的，所以你可以嵌入图片和 emoji 表情，使用预格式化的文本块和其它轻量级的格式。

### **部署** ###

![012509irrtsrpvz8pttqvk.jpg][]

如果你的 pull request 经过审查，并且对应分支通过了测试，这时你就可以在产品中部署你的改动并且验证。如果此分支造成了某些问题，你仍然可以退回到之前的产品进度。

### **合并** ###

![012953qs48434skx1xk5xh.jpg][]

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

一旦进行了合并，Pull Requests 会为你的代码的历史更改保留一份记录。因为它们必须是可搜索的，这样任何人都可以回到过去，了解为什么以及如何会做出这样的决定。

**专业建议**

通过将一些关键字加入到你的 Pull Request 的文本中，你可以将 issues（问题单）和代码关联起来。当你的 Pull Request 被合并的时候，相关的 issues 也将被关闭。例如，输入 Closes \#32 这个短语，表示关闭仓库中第 32 号 issue。更多信息，请查看我们的[帮助文档][Link 2]。

[Link 1]: https://guides.github.com/introduction/flow
[160754qsi6iqyinti3twsh.jpg]: /images/20220326/a701ead58eca4ab9902463c2b4bde1ca.png
[162839wsg5utkulxtucnxg.jpg]: /images/20220326/cb5a41d965314008a7e999e9bf3622dc.png
[164414xfnftde1vyxyzyad.jpg]: /images/20220326/9b737b7b7b5140e2afe4bb78b10f49b6.png
[233122ps7lcba0vwa6nkqq.jpg]: /images/20220326/ec4d349741ca4a22a8c350eeff8a9e8d.png
[012509irrtsrpvz8pttqvk.jpg]: /images/20220326/e6c52df3f64d4b92b8bdaf61e7a0a8eb.png
[012953qs48434skx1xk5xh.jpg]: /images/20220326/a06331567dbb49f79ac50ca6a9c593ac.png
[Link 2]: https://help.github.com/articles/closing-issues-via-commit-messages/