赞
踩
- 严禁所有人员在master节点和develop节点修改提交代码
- master和develop节点只允许合并
- master分支推送必须打上标签,并说明此次详细更改信息
- hotfix:以当前master版本最后一位加1,开发完成后合并至master和develop分支, master主分支打标签
如:master版本为V5.0.1,此时的hotfix分支版本为V5.0.2- feature:从develop分支创建,最后的版本号可自由定义,如1.0.0为当前功能的1.0.0版本
a. 如:feature/wgz_liteflow_1.0.0
b. 另一个同事开发的功能即为:feature/lnc_ordersBug_1.0.0
c. 当feature分支合并至develop分支后,从develop分支拉出release分支,要求加版本号- release:当feature分支合并至develop分支后,拉出新的release分支进行测试,如果出现问题可以release分支进行bug修复,进到bug修复完成,经负责人确定上线后进行合并至master和develop节点,如果暂时不上线,可先合并至develop分支。
a. 命名如:release/wgz_liteflow_V5.1.0
gitflow工作流是一种依赖于Git版本管理工具,按特定规范对项目开发、测试、上线流程进行管理的工作方式。它是一种为实现规范化管理的约定,它明确了各个分支的意义,使整个团队的分工协作更加清晰。
- 【master】
○ 主分支 , 产品的功能全部实现后 , 最终在master分支对外发布
○ 该分支为只读唯一分支 , 只能从其他分支(release/hotfix)合并 , 不能在此分支修改
○ 另外所有在master分支的推送应该打标签做记录,方便追溯
○ 例如release合并到master , 或hotfix合并到master- 【develop】
○ 主开发分支 , 基于master分支克隆
○ 包含所有要发布到下一个release的代码
○ 该分支为只读唯一分支 , 只能从其他分支合并
○ feature功能分支完成 , 合并到develop(不推送)
○ develop拉取release分支 , 提测
○ release/hotfix 分支上线完毕 , 合并到develop并推送- 【featrue】
○ 功能开发分支 , 基于develop分支克隆 , 主要用于新需求新功能的开发
○ 功能开发完毕后合到develop分支(未正式上线之前不推送到远程中央仓库!!!)
○ feature分支可同时存在多个 , 用于团队中多个功能同时开发 , 属于临时分支 , 功能完成后可选删除- 【release】
○ 测试分支 , 基于feature分支合并到develop之后 , 从develop分支克隆
○ 主要用于提交给测试人员进行功能测试 , 测试过程中发现的BUG在本分支进行修复 , 修复完成上线后合并到develop/master分支并推送(完成功能) , 打Tag
○ 属于临时分支 , 功能上线后可选删除- 【hotfix】
○ 补丁分支 , 基于master分支克隆 , 主要用于对线上的版本进行BUG修复
○ 修复完毕后合并到develop/master分支并推送 , 打Tag
○ 属于临时分支 , 补丁修复上线后可选删除
○ 所有hotfix分支的修改会进入到下一个release
- 初始化项目为gitflow , 默认创建master分支 , 然后从master拉取第一个develop分支
- 从develop拉取feature分支进行编码开发(多个开发人员拉取多个feature同时进行并行开发 , 互不影响)
- feature分支完成后 , 合并到develop(不推送 , feature功能完成还未提测 , 推送后会影响其他功能分支的开发),【合并feature到develop , 可以选择删除当前feature , 也可以不删除 . 但当前feature就不可更改了 , 必须从release分支继续编码修改】
- 从develop拉取release分支进行提测 , 提测过程中在release分支上修改BUG
- release分支上线后 , 合并release分支到develop/master并推送,合并之后 , 可选删除当前release分支 , 若不删除 , 则当前release不可修改 . 线上有问题也必须从master拉取hotfix分支进行修改
- 上线之后若发现线上BUG , 从master拉取hotfix进行BUG修改
- hotfix通过测试上线后 , 合并hotfix分支到develop/master并推送,合并之后 , 可选删除当前hostfix , 若不删除 , 则当前hotfix不可修改 , 若补丁未修复 , 需要从master拉取新的hotfix继续修改
- 当进行一个feature时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上【即合并develop到当前feature分支】
- 当进行一个release分支时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上, 即合并develop到当前release分支 (!!! 因为当前release分支通过测试后会发布到线上 , 如果不合并最新的develop分支 , 就会发生丢代码的情况)
● master分支由项目架构、技术leader合并操作,任何人不可在此主分支开发。hotfix分支从master分支拉取
● develop分支由项目架构、技术leader、指定开发组长操作,只读,任何人不在此分支上开发。
● feature分支,由开发人员创建,多个分支,命名规则: feature/姓名_版本号_功能名称,开发人员每日都要从develop合并代码到自己的feature分支,开发完成后,再合并到develop。
● release待提测分支,从develop拉取release版本分支,命名规范:release/版本号,在此分支进行测试,bug修复,完成后打待上线tag,合并代码至develop,----->>>发布上线版本时再合并至master,打tag:规则为:版本号_上线日期_主要需求
● hotfix线上修复版本:从master拉取hotfix分支、命名规则: hotfix/版本号,修复完成,合并到develop和master
注:>>> 开发分支一旦合并至develop分支,即删除当前分支。
首先,代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本,都在这个主分支上发布。
Git主分支的名字,默认叫做Master。它是自动建立的,版本库初始化以后,默认就是在主分支在进行开发。
主分支只用来分布重大版本,日常开发应该在另一条分支上完成。我们把开发用的分支,叫做Develop。
这个分支可以用来生成代码的最新隔夜版本(nightly)。如果想正式对外发布,就在Master分支上,对Develop分支进行"合并"(merge)。
git checkout -b develop master
# 切换到Master分支
git checkout master
# 对Develop分支进行合并
git merge --no-ff develop
这里稍微解释一下,上一条命令的--no-ff参数是什么意思。默认情况下,Git执行"快进式合并"(fast-farward merge),会直接将Master分支指向Develop分支。
使用--no-ff参数后,会执行正常合并,在Master分支上生成一个新节点。为了保证版本演进的清晰,我们希望采用这种做法。
- 功能(feature)分支
- 预发布(release)分支
- 修补bug(fixbug)分支
这三种分支都属于临时性需要,使用完以后,应该删除,使得代码库的常设分支始终只有Master和Develop。
功能分支的名字,可以采用feature/开发人员名称_功能名_版本号的形式命名。如:feature/wgz_dictionary_1.1
git checkout -b feature/wgz_dictionary_1.1 develop
git checkout develop
git merge --no-ff feature/wgz_dictionary_1.1
git branch -d feature/wgz_dictionary_1.1
git checkout -b release/wgz_add-user_1.2 develop
git checkout master
git merge --no-ff release/wgz_add-user_1.2
# 对合并生成的新节点,做一个标签
git tag -a 1.2
git checkout develop
git merge --no-ff release/wgz_add-user_1.2
git branch -d release/wgz_add-user_1.2
git checkout -b fixbug/wgz_add-user_1.1 master
git checkout master
git merge --no-ff fixbug/wgz_add-user_1.1
git tag -a 0.1.1
git checkout develop
git merge --no-ff fixbug/wgz_add-user_1.1
git branch -d fixbug/wgz_add-user_v1.1
- 项目初版本时,版本号可以为 0.1.0;
- 当项目在进行了局部修改或 bug 修正时,主版本号和子版本号都不变,修正版本号加 1;
- 当项目在原有的基础上增加了部分功能时,主版本号不变,子版本号加 1,修正版本号复位为 0;
- 当项目在进行了重大修改或局部修正累积较多,而导致项目整体发生全局变化时,主版本号加 1;
- 主版本号改动:一期项目用0.1.0;二期项目用1.1.0;三期项目用2.1.0;
- 子版本号改动:增加了权限管理功能模块,版本号由0.1.3改为0.2.0;
- 修正版本号改动:修正了一个页面显示字符串,版本号由0.1.3改为0.1.4
git config --list
git config user.name
git config user.password
git config user.name “wugz”
git config user.password “123456”
git config user.email “1053295500@qq.com”
# git config --global user.name 用户命
git config --global user.name wugz
# git config --global user.password 密码
git config --global user.password abc0506abc
# git config --global user.password 邮箱
git config --global user.email “1053295500@qq.com”
git config user.name “wugz”
git config --global user.name “wugz”
● 它们提交测试和部署到线上的时间往往不一样,如何清晰所属分支的职责?
● 不同功能可能会有相互依赖的代码,假设分属于不同的分支,如果其中一方想提交测试,必须先和另外一方合并,但另外一方还没到提交测试的时候,如果没有一个好的分支管理策略,就容易造成分支管理的混乱。
● 不同分支是否应该对应不同的环境,应该如何对应,jenkins 应该如何实现。
● master
● develop
● feature
● release
● fixbug
git checkout -b feature/wgz_order_1.1 develop
# 切换到 develop
git checkout develop
# 合并
git merge --no-ff feature/wgz_order_1.1.0
# 删除 feature/wgz_order_1.1.0
git branch -d feature/wgz_order_1.1.0
# 推送 develop
git push origin develop
# 创建 release/wgz_order_2.0.0 分支
git checkout -b release/wgz_order_2.0.0 develop
# 切换到 master
git checkout master
# 合并 release/wgz_order_2.0.0
git merge --no-ff release/wgz_order_2.0.0
# 标记版本号
git tag -a 2.0.0
# 切换到 develop
git checkout develop
# 合并
git merge --no-ff release/wgz_order_2.0.0
# 删除 release/wgz_order_2.0.0
git branch -d release/wgz_order_2.0.0
# 检出 fixbug/wgz_order_2.0.1
git checkout -b fixbug/wgz_order_2.0.1 master
# 合并 master
git checkout master
git merge --no-ff fixbug/wgz_order_2.0.1
git tag -a 2.0.1
# 合并 develop
git checkout develop
git merge --no-ff fixbug/wgz_order_2.0.1
# 删除 hotfix-2.0.1
git branch -d fixbug/wgz_order_2.0.1
git flow feature start feature/wgz_1.0
git flow feature start feature/wgz_order_1.0
git flow feature start feature/wgz_bill_1.0
git flow feature
git flow feature start feature/wgz_1.0
git flow feature finish feature/wgz_1.0
git flow feature finish feature/wgz_1.0
其它类型的分支类似。
git flow feature start feature/wgz_order_1.0.2
git flow feature start feature/wgz_finance_1.0.2
# 推送到相应的 feature 分支
git flow feature publish feature/wgz_order_1.0.2
# 拉取相应的 feature 分支
git flow feature pull feature/wgz_order_1.0.2
# 完成订单功能开发,自动合并到 develop 并删除 feature-order
git flow feature finish feature/wgz_order_1.0.2
# develop 中的订单功能准备就绪,检出预发布分支,推送时会触发 jenkins 的构建任务,
# 自动部署到测试环境
git flow release start release/wgz_order_1.0.2
# 合并到 master,删除 release/wgz_order_1.0.2
git flow release finish release/wgz_order_1.0.2
# 检出 hotfix/wgz_order_1.0.2
git flow hotfix start fixbug/wgz_order_1.0.2
# 合并到 master
git flow hotfix finish fixbug/wgz_order_1.0.2
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。