ideadevelop分⽀拉取其他分⽀代码_10年经验17张图带你进⼊
fetch最佳用法
gitflow企业项。。。
前⾔
对于项⽬版本管理，你是否存在这样的痛点：项⽬分⽀多⽽杂不好管理，git log界⾯commit信息错乱复杂⽆规范，版本回退不知道选择什么版本合适……。
项⽬版本管理的最佳实践系列，笔者将以两篇⽂章的形式展开介绍（即基础篇与进阶篇）。本⽂为gitflow版本管理的最佳实践-基础篇。基础篇主要介绍git应⽤于⽣产的基本流程与怎么使⽤gitflow管理你的项⽬版本线（适⽤于敏捷迭代的项⽬管理场景下）。进阶篇
阅读本⽂需要有⼀定git基将着重介绍gitflow+jenkins+docker+DevOps+敏捷Scrum 完成项⽬持续构建与持续交付（CI/CD）。 阅读本⽂需要有⼀定git基
本⽂介绍的并不是纯粹的gitflow，⽽础，基础知识则不在本⽂展开，善⽤⽹上冲浪⼯具便可学习到许多Git的基础知识。实际上， 本⽂介绍的并不是纯粹的gitflow 是结合实际⽣产对gitflow的改造与最佳实践。
Git的基本术语与简写
le data-draft-node="block" data-draft-type="table" data-size="normal" data-row->
⼀、分⽀规约
master，三条分⽀对应三
release与master
在我们的最佳实践中，远程版本库永远只存在三条长期且相互独⽴的分⽀
develop、release
永远只存在三条长期且相互独⽴的分⽀，他们分别为develop
个环境，分别为开发环境（集成开发环境）、测试环境（预发环境）与⽣产环境，三个分⽀分别都上权限，不可直接对其进commit操作，即所有的修改均通过PR进⾏，以保证分⽀对应环境的安全与稳定。本地环境对应的远程分⽀均会在PR通过之
⾏push
push与commit
后，⾃动进⾏删除，以保证版本线的简单。
e data-draft-node="block" data-draft-type="table" data-size="normal" data-row->
⼆、版本号规约
在正式介绍gitflow之前，我们需要对版本号进⾏规范，⽅便接下来的⾏⽂展开。
在⽣产中，我们常⽤的版本号为三位数版本号（偶尔带四位热修复号），其构成如下：
V主版本号.次版本号.功能号(.${热修复版本号}).环境
（版本号并不以⼗进制，⽽是按照迭代规划推送）
eg：V1.0.0.1.RELEASE、V1.1.0.DEVELOP、V1.0.0。（版本号并不以⼗进制，⽽是按照迭代规划推送）
2.1 主版本号（⾸位版本号）
主版本号，也叫⾸位版本号、顶位版本号，即V后第⼀个版本号。主版本号⼀般代表项⽬的期数与产品⽅向。除⾮项⽬合同改变、⼤规模api 不兼容、产品⽅向改变、底层架构升级等情况外不轻易更新。
另外，项⽬未正式发布、未正式孵化、未正式上线，则⾸位版本号为0，⼀期发布，则为V1。
2.2 次版本号（迭代号）
次版本号，也叫迭代号，⼀般代表某个迭代发布的功能集合（⼀个迭代发布会包含若⼲个功能更新）。
如V1.1.0：第⼀期项⽬第⼀迭代发布版本、V1.2.0：第⼀期第⼆迭代发布版本。
2.3 功能号（PR号）
⼀般来说，提交到项⽬分⽀内的代码均需要经过PR，⽽为了保证单个PR的简洁性与纯粹性，建议⼀个PR描述⼀个功能。因此第三位数的版本号也叫做PR号或功能号，⽤来描述单个提交到主分⽀内的功能或代码修改。
如V0.0.1：第⼀迭代的第⼀个提交、V0.0.98：第⼀迭代的第98个PR。
2.4 热修复号
四位数版本号是可选版本号，为热修复版本号（也叫⽼爷保号hh），常规迭代与develop分⽀下并不会
出现，⽽常出现在测试环境对应的release分⽀与⽣产环境对应的master分⽀（develop分⽀对应的开发环境出现bug直接提交pr修复并在原来的版本号上+1便可）。这个版本号常⽤于线上热修复，测试环境（预发环境）的热修复。
值得注意的是，四位数版本号经过线上热修复之后，要同步到本地develop环境的情况下，应当在develop分⽀下的三位数版本号上加⼀。
如：master的热修复号为V1.0.0.4，develop分⽀当前版本为V1.1.8.DEVELOP，那么这个修复要同步回develop分⽀保证bug不重现，那么在develop上⾯的版本则为V1.1.9.DEVELOP
2.5 环境号
因为在git中的tag名称是唯⼀的，那么在develop分⽀下出现了V1.0.0的tag，那么在release和master下便不可以再打⼀个tag叫
V1.0.0。因此出现环境号来对分⽀版本进⾏区分（⽣产环境不加环境号）。
环境环境名版本号（⽰例）
三、Gitflow的最佳实践
3.1 总体流程图
3.2 最佳实践举例
这⾥要搬出两位同学进⾏接下来的讲解，他们是【⼸⾏】同学与【阿康】同学。
3.2.1 远程主⼲分⽀创建
版本的最开始（指V0.0.0），代码管理员会初始化远程仓库，并基于master的初始版本创建三条分⽀，他们是:
origin/master(对应⽣产)，origin/release(对应测试环境)，origin/develop(对应开发环境) 并为这三条分⽀设置保护策略，三条分⽀均不允许直接的commit与push修改。
（V0.0.0.DEVELOP、V0.0.0.RELEASE与V0.0.0）。
代码管理员将三个初始版本打上相应的TAG：（V0.0.0.DEVELOP、V0.0.0.RELEASE与V0.0.0）
3.2.2 本地分⽀创建
完成迭代计划会议（迭代版本号为V0.1.0）之后，⼸⾏与阿康他们分别认领了两个任务：【开发功能】⼸⾏，【开发功能2】阿康。
develop_kang分⽀。
develop_gx分⽀与develop_kang
origin/develop 创建本地develop_gx
此时，⼸⾏与阿康会将远程仓库克隆下来，并基于origin/develop
3.2.3 创建PR
两⼈认领任务后进⾏同步开发，⼀段时间后，⼸⾏率先完成【开发功能1】的⼯作，因此他需要将当前开发版本提交到开发环境中进⾏⾃测与前后端联调。但此时【origin/develop】是被保护的状态⽆法被直接提交。因此，⼸⾏需要对当前的开发的版本进⾏PR申请，即创建拉取请求，请求代码管理员对代码进⾏code review，通过后进⾏合并。
此处涉及的步骤⼤致如下：
1、push当前本地分⽀到origin，得到origin/develop_gx。
2、创建PR：即：origin/develop_gx 合并到 origin/develop 的拉取请求
3、等待代码管理员（或⼩组内同学）进⾏code review，若需要修改，则直接在pr中提出注释，作者修改后直接push到远程分⽀中，继续等待代码管理员进⾏code review。
4、通过后，将当前commit list以squash的形式合并到origin/develop中，得到V0.0.1.DEVELOP 的commit
5、最后选择删除origin/develop_gx的远程分⽀
此时，⼸⾏同学完成了第⼀个功能的开发，并在【origin/develop】分⽀上对⾃⼰的pr commit 进⾏tag操作：将此commit记录为
【V0.0.1.DEVELOP】
3.2.4 合并冲突提交版本
不久后，阿康同学也完成了【开发功能2】的开发，他也需要将代码提交到origin/develop分⽀进⾏测试与联调。但此时，origin/develop 已经与他的基版本不⼀样了（基版本为V0.0.0.DEVELOP，远程版本为V0.0.1.DEVELOP，领先⼀个版本）如果直接创建PR，可能因为代码冲突的问题⽆法完成版本合并，如下图。
（推荐直接使⽤ide⾃带的git⼯具，会⽅便不少）
此时阿康需要将origin/develop版本拉取到本地，并执⾏以下操作（推荐直接使⽤ide⾃带的git⼯具，会⽅便不少） //检查远程仓库是否有新版本
git fetch origin
//发现新版本，需要拉取到本地解决冲突后进⾏代码合并
//暂存本地修改
git stash
//拉取远程版本
git pull origin/develop
//取出本地修改
git unstash
//⼿⼯解决冲突(推荐直接使⽤idea)
//提交修改
git commit -m'1、解决冲突合并版本'
使⽤ide⾃带的冲突解决⼯具则如下图
（注意⼀定要和冲突代码的作者商量代码的变更），便可以创建PR，等待团队内同学进⾏code review。团队成员通过之
提交修改后（注意⼀定要和冲突代码的作者商量代码的变更）
【V0.0.2.DEVELOP】，后，阿康的修改便可以成功被合并到origin/develop中进⾏联调与测试了。阿康此时需要将改commit打上tag【V0.0.2.DEVELOP】如下图：
⾄此，V0.1.0所规划的开发⼯作全部完成。
3.2.5 测试环境版本发布
完成V0.1.0版本开发⼯作后，⼸⾏同学认领了⼀个新任务：【V0.1.0版本提测】。正在其他进⾏其他功能开发⼯作的⼸⾏同学此时需要将本地代码stash起来，并将origin/develop分⽀的代码与本地代码进⾏合并（即git pull origin develop操作），并进⾏代码冲突的解决⼯作。
因为要将代码发布到origin/release分⽀进⾏版本提测，所以⼸⾏同学需要同时将origin/release上的代码与本地代码进⾏合并操作（即git pull origin release操作） 并进⾏代码冲突的解决⼯作。
完成git pull origin develop 与git pull origin release 之后，本地会形成⼀个新的commit版本。⼸⾏同学需要将此commit版本通过pr的
3.2.3 步骤的PR创建过程，并通过⽅式合并到 origin/release 上，⽅可完成release分⽀的测试版本发布⼯作。因此⼸⾏同学需要重复 3.2.3
release分⽀的分⽀管理员审批后，⽅可将版本发布到测试环境。
3.2.6 版本标记
将commit通过pr的形式提交到release后，接下来就是对版本进⾏标记的过程，因为此release已经完成了版本的开发⼯作，因此，当前版本在release分⽀上会被标记为【V0.1.0.RELEASE】。⼜因为在develop分⽀上，V0.0.2.DEVELOP版本对应着release的
V0.1.0.RELEASE版本，针对origin/develop的分⽀上的该commit，会被打上第⼆个tag：【V0.1.0.DEVELOP】。
⽽后，对于develop分⽀的tag处理，将会直接从V0.1.0.DEVELOP继续往下⾛（如V0.1.1.DEVELOP等）
3.2.7 热修复
origin/release分⽀对应着测试环境，对于某些情况⽽⾔，测试环境相当于项⽬的beta版本，有可能直接⾯对客户。
那么版本提测之后，测试同学针对该【V0.1.0.RELEASE】版本进⾏各种测试后发现当前版本存在BUG，那么开发的同学就要针对改bug 进⾏热修复。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。