Git_014:最佳敏捷分支策略

标签: Git | 发表时间:2019-12-02 10:06 | 作者:noreply@blogger.com (Unknown)
出处:http://maping930883.blogspot.com/
目前业界有三种分支策略:Git Flow,Github Flow,Gitlab Flow,它们都是采用"功能驱动式开发"(Feature-driven development,FDD)。所谓 FDD,指的是需求是开发的起点,先有需求再有功能分支(feature branch)或者补丁分支(bugfix 或 hotfix branch)。完成开发后,该分支就合并到主分支,然后该分支被删除。

在分析了三种分支策略后,笔者发现三种策略都有某些缺陷,不能完全满足敏捷开发、持续集成、持续部署的要求。

为此,笔者提出最佳敏捷分支策略。


1. 主分支
代码库有两个主分支作为常设分支。

  • master
  • release

1.1 master 分支
master 分支用于日常开发,存放最新的代码。
master 分支对应测试环境,一套代码版本至少需要搭建两套测试环境,分别用于系统测试(由测试人员测试)和验收测试(由业务人员测试)。
如何保护 master 分支❓

1.2 release 分支
release 分支用于跟踪线上版本,存放所有对外正式发行的版本。
release 分支对应生产环境。
所有测试通过后,从 master 分支创建 release 分支,格式型如 release/1.0,同时在该 release 分支上打 Tag,格式型如: 1.0,注意前面不要加 v,v1.0 不符合习惯

如何保护 release 分支❓

2. 临时分支
  • feature
  • bugfix
  • hotfix
2.1  feature 分支
feature 分支是功能分支,用于开发各个功能模块,格式型如 feature/。
开发人员领取各个功能任务后, 从 master 分支创建各自的 feature 分支,通过单元测试和集成测试(由开发人员测试)后,最终合并到 master 分支
所有 feature 分支都合并到 master 分支后,创建系统测试环境,由测试人员进行系统测试;创建验收测试环境,由业务人员进行验收测试。

2.2. bugfix 分支
bugfix 分支是补丁分支,用于修复在测试环境中测试出来的各个 bug,格式型如 bugfix/。
在测试环境中测试出来的 bug,由开发人员领取任务, 从 master 分支创建各自的 bugfix 分支进行修复,开发人员需要为每个 bugfix 单独编写单元测试和集成测试,测试通过后,最终合并到 master 分支

2.3. hotfix 分支
hotfix 分支是热补丁分支,用于修复在生产环境中发现的各个 bug,格式型如 hotfix/。
hotfix 分支对应准生产环境,一套代码版本至少需要搭建两套测试环境,分别用于系统测试(由测试人员测试)和验收测试(由业务人员测试)。
在生产环境中发现的 bug,由开发人员领取任务, 从当前发现问题的 release 分支创建各自的 hotfix 分支进行修复,开发人员需要为每个 hotfix 单独编写单元测试和集成测试,
所有测试通过后,将 hotfix 分支合并到 master 分支,然后创建 release 分支,格式型如 release/1.0.x,同时在该 release 分支上打 Tag,格式型如: 1.0.x,注意前面不要加 v,v1.0 不符合习惯。

参考文献:
1. https://gist.github.com/digitaljhelms/4287848
2. http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
3. https://www.cnblogs.com/doit8791/p/10147321.html
4. https://blog.csdn.net/hu_zhiting/article/details/95030586
5. http://www.ruanyifeng.com/blog/2012/07/git.html
6. https://www.atlassian.com/blog/git/simple-git-workflow-is-simple
7. https://mohamedradwan.com/2018/01/08/promoting-your-application-deployment-to-different-environments-from-branches-with-and-without-feature-toggle/

相关 [git 分支 策略] 推荐:

Git分支管理策略

- - 阮一峰的网络日志
如果你严肃对待编程,就必定会使用" 版本管理系统"(Version Control System). 眼下最流行的"版本管理系统",非 Git莫属. 相比同类软件,Git有很多优点. 其中很显著的一点,就是版本的分支(branch)和合并(merge)十分方便. 有些传统的版本管理软件,分支操作实际上会生成一份现有代码的物理拷贝,而Git只生成一个指向当前版本(又称"快照")的指针,因此非常快捷易用.

多分支开发策略

- - CSDN博客研发管理推荐文章
ü  功能开发 (开发人员). ü  bug修复,包括测试版本的bugfix和生产版本的hotfix (开发人员). ü  版本集成,包括发布测试版本和生产版本 (项目经理). ü  版本测试 (测试人员). ü  保证bug修复与功能开发并行,不会出现堵塞情形. ü  保证可以快速版本集成. 实现方式就是多分支 + 里程碑标记.

Git基础

- Wolf - 潘魏增
上个月末在公司内部作了一次《Git基础》的主题分享. 这里把分享内容公布出来,希望对一些朋友有用. 如果之前没有接触过Git,wikipedia上面已经有非常好的介绍. pdf格式:http://panweizeng.com/download/git-basics-meituan.pdf. keynote格式:http://panweizeng.com/download/git-basics-meituan.key.

Git_014:最佳敏捷分支策略

- - 心有猛虎,细嗅蔷薇
目前业界有三种分支策略:Git Flow,Github Flow,Gitlab Flow,它们都是采用"功能驱动式开发"(Feature-driven development,FDD). 所谓 FDD,指的是需求是开发的起点,先有需求再有功能分支(feature branch)或者补丁分支(bugfix 或 hotfix branch).

Git-rebase 小筆記

- lepture - YORKXIN×YORKXIN
最近剛好有個機會整理很亂的 Git commit tree,終於搞懂了 rebase 的用法,筆記一下. 大家都知道 Git 有個特色就是 branch 開很大開不用錢,但很多 branches 各自開發,總要在適當時機 merge 進去 master. 看過很多 git 操作指南都告訴我們,可以妥善利用 rebase 來整理看似很亂或是中途可能不小心手滑 commit 錯的 commits ,甚至可以讓 merge 產生的線看起來比較簡單,不會有跨好幾十個 commits 的線.

Git 简明教程

- satoru - python.cn(jobs, news)
Git 是一款强大的分布式版本控制系统.在他的官网可以找到已经有很多著名的项目正在使用. Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another.

git架构图解

- - CSDN博客研发管理推荐文章
  最近又遇到Git了,发现网络上Git的资料确实不咋滴,难懂不全面. 至于Git是什么我就不多说了,相比svn上手确实更难. 与svn集中版本库相比较,Git被称作分布式版本库,在分布式的版本库中任何一个库都可以作为中心库看待. 如果说svn是颗树,那么Git就像一张网. Svn在每个目录都有一个.svn文件夹存放信息,而git只在根目录才有,这就决定了svn可以单独拉取某个子目录或者某个文件,而git需要全部拉取.

一些 Git 設定偏好

- dylan - ihower { blogging }
讓 command line 指令列顯示目前處在哪一個 Git Brnach,最早是在 RGBA 看到這一招,非常方便. 請修改家目錄的 ~/.bashrc 或 ~/.bash_profile 檔案:. 記得打開 Git 的 color 設定,這樣 Git 指令的輸出結果才會加上顏色,像是 git status 等:.

Git和Mercurial(Hg)的分析

- gOODiDEA - 译言-电脑/网络/数码科技
来源Analysis of Git and Mercurial. 原文地址:http://code.google.com/p/support/wiki/DVCSAnalysis. (译者注:Mercurial以下简称Hg). 注:这篇分析完成于2008年夏季,当时我们正第一次为Google Code支持DVCS而作的研究工作.

GoogleCode 的 git 使用小记

- Fstone - Gracecode.com
早先就知道 GoogleCode 支持 git,不过一直没时间体验. 近期实在受不了频繁的 svn commit 加上公司的联通网络访问 GoogleCode 实在是慢得让人无法忍受,于是咬咬牙想把 GoogleCode 中那陈年的代码迁移到 git 控制中. 总得来讲,设置 GoogleCode 项目中新的版本控制方案并不复杂,只需要在管理中点击需要的版本控制系统就行.