在上篇文章中, 我提到了 Git 的基本概念和一些本人实际项目中的总结. 然而, 最近读了 Vincent Driessen 写的一篇文章, 觉得他总结的太好了, 站在他肩膀上忍不住将自己的理解分享出来. Vincent Driessen 的文章连接放在本文最下方, 有需要的童鞋可去参考一二.
话不多上, 干货顶上.
分支模型
上述这张图便是一张完整的分支模型. 乍看上去, 似乎有点复杂, 其实理解后非常简单, 并且十分经典. 如果你所在项目代码管理较为混乱, 我相信, 该模型会对你有所帮助.
主要分支
对于完整的项目来讲, 有两个主要分支, 它们的生命周期与项目等同, 即一直会存在:
master 分支
develop 分支
master: 我相信, 每个 Git 用户都非常熟悉该分支, 没错, 这是创建项目时的默认分支. 对于该模型, 我们认为 master 分支上任何一个点, 都是一个稳定的版本, 可以直接部署至产线环境.
develop: 这是 master 的平行分支, 也是项目中持续开发的分支. 该分支的 HEAD 始终反应着下一个版本的最新修改. 所有的 feature 分支代码都往这里合入. 通常, 自动化测试环境都由该分支构建.
当 develop 分支合入了所有需求分支的代码 (下个发布版本所需的功能) 并且稳定时, 将 develop 代码合入到 master 分支, 并打上版本 tag(方便以后版本回溯).
实际项目中, 我们一般不直接从 develop 分支将代码合入至 master 分支, 而是从 develop 拉出 release 分支, 从 release 分支合入 master 分支. 详情往下观看.
次要分支
除了 master 和 develop 分支, 开发模型中还需要其他分支来协同开发, 其生命周期各不相同, 但最终都会被删除.
feature 分支
release 分支
hotfix 分支
feature 分支
当开发团队接到一个新的需求, 从 develop 分支拉出一个 feature 分支, 该功能相关代码均在该分支开发.
当该分支开发完毕, 将分支代码合入 develop 分支;
远端删除该 feature 分支, 当然开发本地可保留该分支一段时间, 防止出现乌龙事件.
本地创建一个 feature 分支:
- # 从本地 develop 分支拉出 feature1 分支
- Git checkout -b feature1 develop
- # 从远端 develop 分支拉出 feature1 分支
- Git checkout -b feature1 origin/develop
将本地分支上传到远端:
- # 将本地新建 feature1 分支上传到远端, 并在远端命名为 feature1
- Git push origin feature1:feature1
- # 将本地新建 feature1 分支上传到远端, 并在远端命名为 feature2
- Git push origin feature1:feature2
查询分支
- # 查询本地分支
- Git branch
- # 查询远端分支
- Git branch -r
- # 查询所有分支
- Git branch -a
本地切换分支
- # 切换到 develop 分支
- Git checkout develop
本地删除分支
- # 删除本地分支 feature1
- Git branch -d feature1
- # 强制删除本地分支 feature1
- Git branch -D feature1
- # 删除远程分支 feature1
- Git push origin :feature1
release 分支
当 develop 分支达到一个稳定点, 从 develop 分支从拉出 release 分支, 将其打包并部署到环境中, 进行系统测试.
如果测试过程中, 出现 bug, 在 release 分支进行 bug 修复, 然后出包再次测试;
该 bug 确认修复后, 将代码合入 develop 分支;
所有测试通过后, 将代码合入 master 分支, 并在 master 分支打 tag(一般对应版本号).
本地分支打 tag
- # 切换 master 分支
- Git checkout master
- # 本地分支打 tag
- Git tag -a 2.0.0 -m 'comments'
- # 本地 tag 上传至远端
- Git push --tags
本地删除 tag
- # 本地删除 tag 2.0.0
- Git tag -d 2.0.0
- # 删除远端 tag 2.0.0
- Git push origin :refs/tags/2.0.0
当发布完成后, 我们可以将远端的 release 分支删除, 当然可以保留本地 release 分支一段时间, 防止乌龙事件.
hotfix 分支
当已发布的版本, 在运行一段时间后, 由于偶然等因素造成 bug, 需紧急修复, 此时从 master 分支拉出 hotfix 分支进行 bug 修复.
当 bug 修复完成后, 将代码分别合入 develop 分支和 master 分支.
合入 master 分支后, 在 master 打上新的 tag(一般是小版本号).
新版本上线后, 远端 hotfix 分支可以删除, 本地 hotfix 分支可以保留一段时间, 防止乌龙事件.
上述内容看完, 再回过头来看最初的分支模型, 是否觉得 so easy 呢~
再次感谢 vincent Driessen, 本文多处图片均是参考该篇 blog 而绘制: A successful Git branching model
来源: https://www.cnblogs.com/cloudman-open/p/12207568.html