目前dev分支已开发上线,需要将dev分支代码合并到master ,然后在主干master上打Tag或里程碑,后续二期需求将从master上再拉取一个分支进行开发,请提供一下详细的操作步骤,谢谢!
git merge dev
解决方式一:撤销合并:直接使用master分支代码,舍弃忽略其他分支代码
#放弃忽略合并
git merge --abort
#重新合并,复现冲突,为演示解决方式二准备
git merge dev
解决方式二:和冲突分支的开发人员协商,确定最终保留代码,手动删除冲突
和冲突分支的开发人员协商,确定最终保留代码,手动删除冲突
查看当前分支状态,并提交
git status
git add .
//这里不需要描述 -m,接下来会进入一个可编辑的页面:这里输入描述
git commit
此时在英文模式下,按i,进入可编辑状态
先按 按键esc 退出编辑状态,在英文状态下,再按 :wq ,退出该页面
查看状态
git status --用这一个也可以
git log --pretty=oneline
git push -u origin master
1.master
2.develop
一个项目的代码库至少要有master和develop这两个分支。团队成员从主分支(master)获得的都是处于可发布状态的代码,而从开发分支(develop)应该总能够获得最新开发进展的代码。
- 从master上获得的代码一定要保证是和线上运行的程序是一致的。
- 从develop上获得的应该是最新的稳定版本的代码。
除了基础分支外,我们还需要辅助分支。辅助分支大体包括如下几类:“管理功能开发”的分支、“帮助构建可发布代码”的分支、“可以便捷的修复发布版本关键BUG”的分支。
辅助分支的最大特点就是“生命周期十分有限”,完成使命后即可被删除。
- Feature branch
- Release branch
- Hotfix branch
从develop分支检出,最终也会合并于develop分支。常用于开发一个独立的>新功能,且其最终的结局必然只有两个,其一是合并入“develop”分支,其二>是被抛弃。最典型的“Fearture branches”一定是存在于团队开发者那里,而>不应该是“中心版本库”中。
通过下面的命令来解释这个流程
git checkout -b myfeature develop
#在myfeature上开发完代码之后,需要合并到develop分支上
git checkout develop
git merge myfeature
git branch -d myfeature
git push origin develop从develop分支检出,最终合并于“develop”或“master”分支。这类分支建议命名为“release-*”。通常负责“短期的发布前准备工>作”、“小bug的修复工作”、“版本号等元信息的准备工作”。与此同时,“develop”分支又可以承接下一个新功能的开发工作了。在一>段短时间内,在“Release branch”上,我们可以继续修复bug。在此阶段,严禁新功能的并入,新功能应该是被合并到“develop”>分支的。“Release branch”产生新提交的最好时机是“develop”分支已经基本到达预期的状态,至少希望新功能已经完全从“Feature >branches”合并到“develop”分支了。
经过若干bug修复后,“Release branches”上的代码已经达到可发布状态,此时,需要完成三个动作:第一是将“Release >branches”合并到“master”分支,第二是一定要为master上的这个新提交打Tag(记录里程碑),第三是要将“Release branches”>合并回“develop”分支。
通过下面的命令来解释这个流程
git checkout -b release-1.2 develop
#修改版本号等元信息的准备工作或者小bug的修复工作后 要合并到master
git checkout master
git merge release-1.2
git tag -a 1.2 #发布前要建立里程碑
#如果有bug的修改,还需要合并到develop
git checkout develop
git merge release-1.2
git branch -d release-1.2 #最后删除这个发布分支,它已经完成使命从“master”检出,合并于“develop”和“master”,通常命名为“hotfix-*”
建议设立“Hotfix branches”的原因是:线上总是可能产生非预期的关键BUG,希望避免“develop分支”新功能的开发必须为BUG修复让路的情况。
BUG修复后,需要将“Hotfix branches”合并回“master”分支,同时也需要合并回“develop”分支
通过下面的命令来解释这个流程
git checkout -b hotfix-1.2.1 master
#修复完BUG之后,要合并到master
git checkout master
git merge hotfix-1.2.1
git tag -a 1.2.1 #修改线上BUG需要打标签
#修复完BUG之后,也要合并到develop
git checkout develop
git merge hotfix-1.2.1
git branch -d hotfix-1.2.1 #最后hotfix的分支使命完成,删除之
这就是一个非常好的分支管理模型。
所以,在我们的gitlab上面我们一定至少要有2个分支
master 永远保持和线上代码同步,在上线部署时从这个分支拉去代码打包。如果我们的DI工具到时的功能完善,则DI工具直接从这个分支去代码打包发布
develop 我们的持续集成工具从每天从这个分支上取代码编译大包部署到测试环境(KVM,Docker)。
每次上线前都要建立里程碑Tag
git log --oneline 查看简化的提交记录git log --oneline --graph 查看当前分支提交版本路线
1.在github上dev分支下,创建两个xiaoli分支和xiaohuang分支 2.在本地复制一份代码:命名为xiaoli 和xiaohuang
git log --oneline --graph --all 查看所有分支的版本路线图
git log --oneline --graph 【-number】 查看当前分支提交版本路线图3.分别在以上两个项目下,进行如下操作:
在终端fetch远程仓库代码
git fetch
查看所有的分支
git branch -av
删除远程分支 #删除远程分支之前,确保该分支不用了 以及 确保该分支代码都merge到主分支上
git push origin --delete xiaoli
在github上,查看是否被删除
回答:
将已上线的git dev分支合并到主干master并在master上打tag或里程碑的操作步骤:
git checkout master
git pull
git checkout -b backup_master_20211220
git push --set-upstream backup_master_20211220
git merge dev
git tag <tag_name>
git push origin <tag_name>
其中为要打的tag名字,也可以修改为里程碑名字。推送tag至远程仓库。
将主干master分支上的二期需求拉取到新分支的操作步骤:
git checkout master
git pull
git checkout -b new_branch
注:若该问题还存在特定的分支版本管理策略和开发流程,可以根据实际情况作出调整和修改。
以下是将dev分支合并到master并打Tag步骤:
1.首先,在本地仓库的dev分支和远程仓库的dev分支上确保代码都是最新的。使用以下命令拉取远程仓库的最新代码:
$ git fetch origin dev
2.切换到本地仓库的master分支:
$ git checkout master
3.合并dev分支到当前的master分支:
$ git merge dev
4.执行上述命令后,Git 会自动打开一个编辑器请求您输入有关本次合并操作的注释信息。输入相关的备注信息并保存并关闭编辑器即可执行提交操作。
$ git commit -m "merge dev into master"
5.推送合并后的代码到远程master分支
$ git push origin master
6.在主干master上打标签或里程碑:
可以用以下两种方式之一,在master分支上打上一个具有意义的标签名以及说明:
使用git tag命令
$ git tag -a v1.0 -m "release version 1.0"
或在GitHub、GitLab等网页端操作
7.创建二期需求的开发分支
二期需求对应的开发分支可基于更新的已合并过的master分支创建。以下是创建开发分支的命令:
$ git checkout -b feature/二期需求 origin/master
其中,-b选项表示创建新的分支。 feature/二期需求 表示创建名称为 feature/二期需求 的分支。
8.推送开发分支到远程仓库
$ git push origin feature/二期需求