当前位置:   article > 正文

关于Git Flow的初步认识与学习_feature合到develop后不发版

feature合到develop后不发版

GitFlow(flow:流)

Git流

一种对于代码分支的管理方法,用来应对开发流程的变更。(简化管理提高效率

特点:GitFlow设计非常全面,考虑到了实际开发过程中的各种问题,都能稳定应对,是非常适合大型项目的代码管理。

Git主要优点:

1、分布式存储,本地仓库包含了远程仓库的所有内容,安全性高。(即使远程仓库文件丢失了也不怕)分布式存储

2、优秀的分支模型,创建/合并分支非常方便。

3、方便快速,由于代码本地都有存储,所以从远程拉取和分支合并时都非常快捷。

拓展点:分布式存储

img

img

GitFlow的常用分支

  • 主干分支(具有无限生命周期)

    • Master(主分支,Production(生产))

    • Develop(主开发分支)

  • 支持分支

    • Feature(功能分支,功能开发分支)

    • Release(发布分支,测试分支)

    • Hotfix(修补程序分支)

master分支

  • 具有无限生命周期的分支

  • 主分支, 产品的功能全部实现后 , 最终在master分支对外发布

  • 该分支为只读唯一分支 , 只能从其他分支(release/hotfix)合并 , 不能在此分支直接修改

  • 另外所有在master分支的推送应该打标签(Tag)做记录,方便追溯

  • 例如release分支合并到master分支 , 或hotfix分支合并到master分支

develop分支

  • 具有无限生命周期的分支

  • 主开发分支 , 基于master分支克隆

  • 包含所有要发布到下一个release的代码

  • 该分支为只读唯一分支 , 只能从其他分支合并

  • feature功能分支完成 , 合并到develop(不推送)

  • develop拉取release分支 , 提测

  • release/hotfix 分支上线完毕 , 合并到develop并推送

feature分支

  • 功能开发分支 , 基于develop分支克隆 , 主要用于新需求新功能的开发

  • 功能开发完毕后合到develop分支,进入下一个release分支(未正式上线之前不推送到远程中央仓库!!!)

  • feature分支可同时存在多个 , 用于团队中多个功能同时开发 , 属于临时分支 , 功能完成后可选删除

  • 功能分支通常只存在于开发者仓库中,而不存在于origin(origin:存储库,亦或远程中央仓库)

功能分支的本质在于,只要该功能处于开发阶段,它就存在,但最终会被合并回develop(明确将新功能添加到即将发布的版本中)或丢弃(以防实验令人失望)。

release分支

  • 测试分支 , 基于feature分支合并到develop之后 , 从develop分支克隆

  • 主要用于提交给测试人员进行功能测试 , 测试过程中发现的BUG在本分支进行修复 , 修复完成上线后合并到develop/master分支并推送(完成功能) , 打Tag

  • 属于临时分支 , 功能上线后可选删除

(记住:一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)

发布Release分支时,合并Release到Master和Develop, 同时在Master分支上打个Tag记住Release版本号,然后可以删除Release分支了。

hotfix分支

  • 补丁分支 , 基于master分支克隆 , 主要用于对线上的版本进行BUG修复

  • 修复完毕后合并到develop/master分支并推送 , 打Tag

  • 属于临时分支 , 补丁修复上线后可选删除

  • 所有hotfix分支的修改会进入到下一个release

关于Git Flow的使用(主要流程)

1、Master/Develop分支

  • 初始化项目为gitflow , 默认创建master分支 , 然后从master拉取第一个develop分支

(所有在Master分支上的Commit应该打上Tag,一般情况下Master不存在Commit)

2、Feature分支

  • 从develop拉取feature分支进行编码开发(多个开发人员拉取多个feature同时进行并行开发 , 互不影响)

注意点: feature分支完成后 , 合并到develop(不推送 , feature功能完成还未提测 , 推送后会影响其他功能分支的开发)合并feature到develop , 可以选择删除当前feature , 也可以不删除 . 但当前feature就不可更改了 , 必须从release分支继续编码修改

3、Release分支

  • Release分支基于Develop分支创建,打完Release分支之后,我们可以在这个Release分支上测试,修改Bug等。

  • 同时,其它开发人员可以基于Develop分支新建Feature (记住:一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)发布Release分支时,合并Release到Master和Develop, 同时在Master分支上打个Tag记住Release版本号,然后可以删除Release分支了。

    (从develop拉取release分支进行提测 , 提测过程中在release分支上修改BUGrelease分支上线后 , 合并release分支到develop/master并推送 合并之后 , 可选删除当前release分支 , 若不删除 , 则当前release不可修改 . 线上有问题也必须从master拉取hotfix分支进行修改)

4、Hotfix分支

img

  • Hotfix分支基于Master分支创建,开发完成后需要合并回Master、Develop分支上,同时并在Master分支上打上Tag

    ( 上线之后若发现线上BUG , 从master拉取hotfix进行BUG修改)

    (hotfix通过测试上线后 , 合并hotfix分支到develop/master并推送,合并之后 , 可选删除当前hostfix , 若不删除 , 则当前hotfix不可修改 , 若补丁未修复 , 需要从master拉取新的hotfix继续修改)

注意事项:!!!

当进行一个feature时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上

合并develop到当前feature分支

当进行一个release分支时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上

即合并develop到当前release分支 (!!! 因为当前release分支通过测试后会发布到线上 , 如果不合并最新的develop分支 , 就会发生丢代码的情况)

Git Flow 命令示例

创建 Devlop

  1. git branch develop  
  2. git push -u origin develop

开始 Feature

  1. # 通过develop新建feaeure分支
  2. git checkout -b feature develop
  3. # 或者, 推送至远程服务器:
  4. git push -u origin feature    
  5. # 修改md文件  
  6. git status
  7. git add .
  8. git commit    

完成 Feature

  1. git pull origin develop
  2. git checkout develop
  3. #--no-ff:不使用fast-forward方式合并,保留分支的commit历史
  4. #--squash:使用squash方式合并,把多次分支commit历史压缩为一次
  5. git merge --no-ff feature
  6. git push origin develop
  7. git branch -d some-feature
  8. # 如果需要删除远程feature分支:
  9. git push origin --delete feature  

开始 Release

git checkout -b release-0.1.0 develop

完成 Release

  1. git checkout master
  2. git merge --no-ff release-0.1.0
  3. git push
  4. git checkout develop
  5. git merge --no-ff release-0.1.0
  6. git push
  7. git branch -d release-0.1.0
  8. git push origin --delete release-0.1.0  
  9. # 合并master/devlop分支之后,打上tag
  10. git tag -a v0.1.0 master
  11. git push --tags

开始 Hotfix

git checkout -b hotfix-0.1.1 master  

完成 Hotfix

  1. git checkout master
  2. git merge --no-ff hotfix-0.1.1
  3. git push
  4. git checkout develop
  5. git merge --no-ff hotfix-0.1.1
  6. git push
  7. git branch -d hotfix-0.1.1
  8. git push origin --delete  hotfix-0.1.1
  9. git tag -a v0.1.1 master
  10. git push --tags

SourceTree

【不喜欢命令行的同学 , 这里有完美支持Git Flow的图形化工具 - SourceTree(支持中文简体)】

SourceTree官网地址

GitFlow在实践中有几个问题

  • 因为大家都在自己的Feature分支上面开发,特别是对于长期的Feature分支会可能存在严重的合并冲突问题,需要花费大量的时间解决;

  • 同样是基于第一条,导致Feature分支之间相互隔离,以至于CI/CD困难,单个功能可能没有问题,但合并以后是否也没问题谁也无法保证。

结语

本帖文章图片等等来源于网络,仅作为学习之用,版权归原作者所有.如果侵犯了您的权益,请来信告知,我会尽快删除.

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。


本文相关知识点溯源:

摘取于:

Git Flow 的正确使用姿势

作者:qingwenLi

链接:https://www.jianshu.com/p/41910dc6ef29

来源:简书

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

GitFlow详解教程

作者:BlueKitty1210

原文链接:https://blog.csdn.net/xingbaozhen1210/article/details/81386269

来源:CSDN

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

谈谈代码分支管理

作者:来自知乎用户

原文链接:https://zhuanlan.zhihu.com/p/93125600

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

分布式存储是什么?

作者:知乎用户

原文链接:https://www.zhihu.com/question/20001516/answer/646911739

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

一个成功的 Git 分支模型

作者:Vincent Driessen

原文链接:https://nvie.com/posts/a-successful-git-branching-model/

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

CI/CD

原文链接:https://linux.cn/article-9926-1.html

欢迎大家一起学习讨论!

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/爱喝兽奶帝天荒/article/detail/917316
推荐阅读
相关标签
  

闽ICP备14008679号