Master 分支

  1. Master 分支应该始终和生产环境保持一致。
  2. 由于 master 和生产代码是一致的，所以没有人包括技术负责人能在 master 上直接开发。
  3. 真正的开发代码应当写在其他分支上。

Release(发布) 分支

  1. 当项目开始时，第一件事情就是创建发布分支。发布分支是基于 master 分支创建而来。
  2. 所有与本项目相关的代码都在发布分支中，这个分支也是一个以 release/ 开头的普通分支。 比如这次的发布分支名为 release/fb。
  3. 可能有多个项目都基于同一份代码运行，因此对于每一个项目来说都需要创建一个独立的发布分支。假设现在还有一个项目正在并行运行，那就得为这个项目创建一个单独的发布分支比
  4. Feature(功能分支) branch 如 release/messenger。
  5. 需要单独的发布分支的原因是：多个并行项目是基于同一份代码运行的，但是项目之间不能有冲突。

Feature(功能分支) branch

  1. 对于应用中的每一个功能都应该创建一个独立的功能分支，这会确保这些功能能被单独构建。
  2. 功能分支也和其他分支一样，只是以 feature/ 开头。
  3. 现在作为技术 Leader，你要求 Alice 去做 Facebook 的登录页面。因此他创建了一个新的功能分支。把他命名为 feature/login。Alice 将会在这个分支上编写所有的登录代码。
  4. 这个功能分支通常是基于 Release(发布) 分支 创建而来。
  5. Bob 的任务为创建添加好友页面，因此他创建了一个名为 feature/friendrequest 的功能分支。
  6. John 则被安排构建消息流，因此创建了一个 feature/newsfeed 的功能分支。
  7. 所有的开发人员都在自己的分支上进行开发，目前为止都很正常。
  8. 现在当 Alice 完成了他的登录开发，他需要将他的功能分支 feature/login 发送给 Release(发布) 分支。这个过程是通过发起一个 pull request 完成的。

Pull request

首先 pull request 不能和 git pull 搞混了。

开发人员不能直接向 Release(发布) 分支推送代码，技术 Leader 需要在功能分支合并到 Release(发布) 分支之前做好代码审查。这也是通过 pull request 完成的。

代码冲突

通常有两种方式来解决代码冲突：

  • pull request 的 reviewer 需要解决所有的代码冲突。
  • 开发人员需要确保将发布分支的最新代码合并到功能分支，并且解决所有的冲突。

还是 Master 分支

一旦项目完成，发布分支的代码需要合并回 master 分支，同时需要发布到生产环境。

因此生产环境中的代码总是和 master 分支保持一致。同时对于今后的任何项目来说都是要确保 master 代码是最新的。