Git分支管理规范的方法是什么

这篇文章主要介绍“Git分支管理规范的方法是什么”，在日常操作中，相信很多人在Git分支管理规范的方法是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”Git分支管理规范的方法是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！master：主分支，不允许开发者推送代码，只有一个develop：开发分支，也只有一个feature：新功能分支，在develop分支上创建，用于开发新功能，若存在多个新特性可以并行开发，则开发主管可创建多个feature 分支(特性分支)，命名规范:feature-分支创建日期-新特性关键字，例如:feature-20200911-i18nrelease：准备发布新版本时的发布分支。开发完毕，则创建 release 分支(发布分支)，命名规则:release-分支创建日期-待发布版本号。例如:release-20200911-v1.0.0hotfix：热修复分支，用于线上修复bug，从master分支创建。命名规则:hotfix-分支创建日期-待发布版本号，例如:hotfix-20200911-v1.0.1开发人员在 develop 分支上实现新功能，包括：新特性与 新特性的Bug 修复命令示例：存在多个新特性可以并行开发，则开发主管可创建一个或多个 feature 分支(特性分支)，命名规范:feature-分支创建日期-新特性关键字，例如:feature-20200911-i18n。当新特性开发完毕后，开发主管需将 feature 分支合并到 develop 分支，最后需删除 feature 分支。开发一个独立的新特性(完成时，需合并到 develop 分支)技术研究与尝试(若失败，可随时删除 feature 分支)提前实现下一个版本需要开发的特性(可不在本次迭代中发布)推荐使用 feature 分支，但 feature 分支的生命周期不能跨一次迭代发布新版本的前提：确认 develop 分支上的功能是否开发完毕若开发完毕，则创建 release 分支(发布分支)，命名规则:release-分支创建日期-待发布版本号，例如:release-20200911-v1.0.0首先在 release 分支中升级 Maven 版本号，例如:1.0.0-SNAPSHOT，然后修改 version.ini 文件(便于在部署时查看当前版本号)，最后在 release 分支上做一次提交通知测试可对 release 分支进行测试开发人员在 release 分支上修复测试人员提交给自己的 Bug第一步:集成测试
测试需完成以下任务:从 release 分支上检出所有代码并搭建集成测试环境安排测试人员，对 release 分支进行集成测试通知开发主管当前版本已集成测试完毕第二步:冒烟测试
开发主管需完成以下任务:将 release 分支同时合并到 master 分支与 develop 分支通知测试主管，对 master 分支进行冒烟测试第三步:发布新版本
开发主管需完成以下任务:修改 master 分支上的 Maven 快照版为发布版(去掉 SNAPSHOT 后缀)添加发布日志(RELEASE.md)在 master 分支上创建标签，命名规则:tag-日期-版本，例如:tag-20200911-v1.0.0删除 release 分支打包并上传 Maven 私服第一步:创建 hotfix 分支 开发主管需完成以下任务:从 master 分支某个 tag 上创建一个 hotfix 分支(热修复分支)，命名规则:hotfix-分支创建日期-待发布版本号，例如:hotfix-20200911-v1.0.1首先在 hotfix 分支中升级 Maven 版本号(例如:1.0.1-SNAPSHOT)，然后修改 version.ini 文件，最后在hotfix 分支上做一次提交指导开发人员完成 Bug 修复通知测试对 hotfix 分支进行测试Bug修复测试通过后：将 hotfix 分支同时合并到 master 与 develop 分支通知测试进行冒烟测试修改 master 分支上的 Maven 快照版为发布版(去掉 SNAPSHOT 后缀)添加发布日志(RELEASE.md)在 master 分支上创建标签删除 hotfix 分支打包并上传 Maven 私服比如:现在 master 分支已 香港云主机经发布了 2.0.0 版本(代码结构发生了很大的变化)，但线上发现了一个 1.0.0 版 本的 Bug，当修改了 Bug后，是无法再合并到 master 与 develop 分支的，开发需完成以下任务:直接在 hotfix 分支上创建标签删除 hotfix 分支(分支删除了，只要标签还在，版本就可以找得回来)手工修改 develop 分支中的代码(在后续发布时再合并到 master 分支中)当需要对某项目进行定制化时，可从源项目的 Git 仓库 fork 出一个新的 Git 仓库:当 fork 后，对 repo1 做出的任何修改，都不会影响到 repo2
在 repo2 中修复了 Bug，可通过 Merge Request 的方式提交给 repo1
在 repo2 中可随时拉取 repo1 中的提交，但 repo1 不能拉取 repo2 中的提交到此，关于“Git分支管理规范的方法是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注开发云网站，小编会继续努力为大家带来更多实用的文章！

相关推荐: Mac剪切板记录管理工具Paste的原理和用法是什么

这篇文章将为大家详细讲解有关Mac剪切板记录管理工具Paste的原理和用法是什么，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。它的设计风格是卡片式，每一段保存的剪切内容都已独立的卡片形式存在，同时显示内容来源和…