这是我参与「第三届青训营 -后端场」笔记创作活动的的第4篇笔记
Git 工作流
每当项目有多个开发者参与时，正确的 Git 工作流就显得非常重要了。下面我会介绍一个在多人大项目中非常有效的工作流。
Git 开发流程
Master branch （主分支）
-
Master 分支应该始终有生产环境代码(production code）的副本
-
任何人（包括技术负责人在内）都不允许直接在 master 分支上写代码，因为它只是生产环境代码的副本
-
实际代码写在其他分支中
Release branch （发布分支）
-
项目开始时，首先要为项目创建 release branch。 release branch是从 master branch 创建的。
-
与此项目有关的所有代码都在 release branch 里。release branch 其实只是一个前缀为release/ 的普通分支。
-
让我们把这个例子中的 release branch 取名为 release/fb。
-
由于同一代码库上可能运行着多个项目，所以需要为每一个项目创建一个单独的 release branch。假设还有另一个项目同时运行着，那么这个项目就有一个比如叫 release/messenger 的单独的 release branch。
-
Release branch 的存在是为了让同一代码库能同时运行多个项目而不会相互干扰。
Feature branch （功能分支）
-
对于构建在应用程序中的每个功能，都会创建一个单独的 feature 分支。这确保了各个功能能被独立构建。
-
Feature 分支只是有着 feature/ 前缀的普通分支。
-
现在，作为技术负责人的你让 Alice 给你们的 Facebook 写一个登陆界面，于是她创建了一个新的 feature 分支，我们就叫它 feature/login。Alice 将会把所有登陆环节的代码都写在这个 feature 分支上。
-
这个 feature 分支是从你们的 release 分支创建的。
-
Bob 的任务则是写添加好友页面，所以Bob 创建了一个叫做 feature/friendrequest的 feature 分支。
-
John 的任务是构建 newsfeed，所以John创建了名叫 feature/newsfeed 的 feature 分支。
-
所有开发者写的代码都在他们各自的feature 分支，到目前为止一切顺利。
-
现在，假设 Alice 已经完成了登陆代码，她需要把代码从她的 feature 分支 feature/login 发送到 release 分支 release/fb。这是通过 pull 请求 完成的。
pull请求（Pull Request)
首先要指出，pull 请求和 git pull是两回事。
开发者不能直接把代码推送到 release 分支。feature 分支上的代码需要经过技术负责人的审查，才能推送到 release 分支。这时候需要 pull 请求。
当项目完成，release 分支里的代码被合并到 master 分支，然后代码被部署到生产中。因此，生产中的代码和 master 分支中的代码始终保持同步。 这也确保了对于任何未来的项目， master 分支中都提供了最新的代码。
恭喜 ，你现在 get 使用 Git 的正确姿势了！Git 还有一些别的概念如修改提交、重写历史等同样很有用，但 Git 工作流对于大项目的成功来说至关重要。
