项目的GIT分支管理

概览

一个项目涉及到多个模块多个团队进行开发时，则需要将git分支进行规范化管理

这种模式下，主要维护两类分支：

• 主要分支
  • master
  • develop
• 辅助分支
  • featrue branch（功能分支）
  • hotfixes branch（热修复分支）

master

代码库中有且只有一个主分支，master 分支的代码是最稳定的，可以随时发布到生产环境。

develop

用于日常开发，保存开发过程中最新的代码。
当 develop 分支上的代码达到稳定时，并具备发版状态时，将 develop 的代码合并到 master，并且打一个带有发布版本号的 tag。

feature

从 develop 分支上拉取一个新的分支，开发某个新的功能，开发完成之后，在合并到 develop 分支，功能分支通常只存在于开发者的本地仓库，并不包含在远程库中。

hotfix

从 master 分支上拉取，为修复分支。软件正式发布之后难免会出现bug，会在hotfix上进行代码修复。修复结束之后合并到 master 和 develop 分支上。

总结

优点：

1. 各个分支职责分明，是很多分支管理策略的启蒙模型

缺点：

1. 合并冲突：多个分支可能会很多，有一些并行的feature 分支，很有可能发生冲突。频繁手动解决冲突不仅增加了工作量，而且增大了出错的风险。
2. 功能分离：并行开发时，合并分支前无法测试组合功能，而且合并之后可能会有影响。
3. 无法持续交付：一个 feature 分支要经历很多步骤才能发不到正式环境，难以达到交付的要求。
4. 无法持续集成：持续集成鼓励更加频繁的代码集成和交互，尽早解决冲突。而 Git Flow 的分支策略隔离了代码，尽可能推迟代码集成。