在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master
分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev
分支上,也就是说,dev
分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev
分支合并到master
上,在master
分支发布1.0版本;
你和你的小伙伴们每个人都在dev
分支上干活,每个人都有自己的分支,时不时地往dev
分支上合并就可以了。
通常,合并分支时,如果可能,Git会用Fast forward
模式,但这种模式下,删除分支后,会丢掉分支信息。
如果要强制禁用Fast forward
模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。
下面我们实战一下--no-ff
方式的git merge
:
首先,仍然创建并切换dev
分支:
$ git checkout -b dev
Switched to a new branch 'dev'
修改readme.txt文件,并提交一个新的commit:
$ git commit readme.txt -m "branch manager"
[dev 4c49945] branch manager
1 file changed, 1 insertion(+)
现在,我们切换回master
:
$ git checkout master
Switched to branch 'master'
准备合并dev
分支,请注意--no-ff
参数,表示禁用Fast forward
:
$ git merge --no-ff -m "merger with no-ff" dev
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+)
因为本次合并要创建一个新的commit,所以加上-m
参数,把commit描述写进去。
合并后,我们用git log
看看分支历史:
$ git log --graph --pretty=oneline --abbrev-commit * 7fbc277 merger with no-ff |\ | * 4c49945 branch manager |/ * 0f3d64a fixed conflicts |\ | * b4309b0 create new branch feature1 first modify * | 0b56936 goback master first modify |/ * 45ae9a9 create new branch.... * 90bc1f7 test name .......
Bug分支
软件开发中,bug就像家常便饭一样。有了bug就需要修复,在Git中,由于分支是如此的强大,所以,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。
当你接到一个修复一个代号001的bug的任务时,很自然地,你想创建一个分支bug-001
来修复它,但是,等等,当前正在dev
上进行的工作还没有提交:
$ git status On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a")
并不是你不想提交,而是工作只进行到一半,还没法提交,预计完成还需1天时间。但是,必须在两个小时内修复该bug,怎么办?
幸好,Git还提供了一个stash
功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:
$ git stash
Saved working directory and index state WIP on dev: e980635 dev
HEAD is now at e980635 dev
现在,用git status
查看工作区,就是干净的(除非有没有被Git管理的文件),因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug,假定需要在master
分支上修复,就从master
创建临时分支:
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 9 commits.
(use "git push" to publish your local commits)
$ git checkout -b bug-001
Switched to a new branch 'bug-001'
现在修复bug,需要把“git branch manager....”改为“git branch manager....modify”,然后提交:
$ git add readme.txt
$ git commit -m "bug modify"
[bug-001 3b8d00c] bug modify
1 file changed, 1 insertion(+), 1 deletion(-)
修复完成后,切换到master
分支,并完成合并,最后删除issue-101
分支:
$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 9 commits. (use "git push" to publish your local commits) $ git merge --no-ff -m "merge bug fix 001" bug-001 Merge made by the 'recursive' strategy. readme.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
太棒了,原计划两个小时的bug修复只花了5分钟!现在,是时候接着回到dev
分支干活了!
$ git checkout dev
Switched to branch 'dev'
$ git status
On branch dev
nothing to commit, working directory clean
工作区是干净的,刚才的工作现场存到哪去了?用git stash list
命令看看:
$ git stash list
stash@{0}: WIP on dev: e980635 dev
工作现场还在,Git把stash内容存在某个地方了,但是需要恢复一下,有两个办法:
一是用git stash apply
恢复,但是恢复后,stash内容并不删除,你需要用git stash drop
来删除;
另一种方式是用git stash pop
,恢复的同时把stash内容也删了:
$ git stash pop On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a") Dropped refs/stash@{0} (9bfeed878d4c504cf12c67a6965db13506567b4a)
再用git stash list
查看,就看不到任何stash内容了:
$ git stash list
你可以多次stash,恢复的时候,先用git stash list
查看,然后恢复指定的stash,用命令:
$ git stash apply stash@{0}
小结
修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除;
当手头工作没有完成时,先把工作现场git stash
一下,然后去修复bug,修复后,再git stash pop
,回到工作现场。
Feature分支
软件开发中,总有无穷无尽的新的功能要不断添加进来。
添加一个新功能时,你肯定不希望因为一些实验性质的代码,把主分支搞乱了,所以,每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后,删除该feature分支。
现在,你终于接到了一个新任务:开发代号为Vulcan的新功能,该功能计划用于下一代星际飞船。
于是准备开发:
$ git checkout -b feature-vulcan
Switched to a new branch 'feature-vulcan'
5分钟后,开发完毕:
$ git add readme.txt $ git status On branch feature-vulcan Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: readme.txt
$ git commit -m "add feature-vulcan" [feature-vulcan 939d622] add feature-vulcan 1 file changed, 4 insertions(+), 2 deletions(-)
切回dev
,准备合并:
$ git checkout dev
Switched to branch 'dev'
一切顺利的话,feature分支和bug分支是类似的,合并,然后删除。
但是,
就在此时,接到上级命令,因经费不足,新功能必须取消!
虽然白干了,但是这个分支还是必须就地销毁:
$ git branch -d feature-vulcan
error: The branch 'feature-vulcan' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature-vulcan'.
销毁失败。Git友情提醒,feature-vulcan
分支还没有被合并,如果删除,将丢失掉修改,如果要强行删除,需要使用命令git branch -D feature-vulcan
。
现在我们强行删除:
$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 939d622).
小结
开发一个新feature,最好新建一个分支;
如果要丢弃一个没有被合并过的分支,可以通过git branch -D <name>
强行删除。
相关推荐
git分支管理策略,git分支管理策略,git分支管理策略,git分支管理策略
Git分支管理的策略梳理
作为开发人员,我比今天其他所有工具都更喜欢Git。Git确实改变了开发人员对合并和分支 的看法。文章谈论了git分支策略和发布管理技巧,帮助开发人员有效管理各个开发版本。
在这篇文章中,我提出一个开发模型。我已经将这个开发模型引入到我所有的项目里(无论 在工作还是私人...我不会讲任何项目的具体细节,仅是关于分支策略和释放管理相关内容。 它主要体现了Git对我们源代码版本的管理。
基于项目的学习活动,面向开始使用Git进行分支的人员。 您可以在以下位置玩游戏: : 支持的浏览器:Chrome,Firefox,Safari,Opera和IE9 + 这个有趣的开源游戏是从以下网站克隆的: : 初始回购设置(学生) ...
分支管理的策略,它可以使得版本库的演进保持简洁,主干清晰,各个分支各司其职、井井有条.
CI/CD(持续集成/持续交付)策略以及git分支模型和以前的项目做一下分析比较,希望对各位有所帮助,也能有所思考,尤其是那些期望 搭建项目部署流水线或者想了解git分支模型的开发、运维人员。 废话不多说,由于近期...
如果你严肃对待编程,就必定会使用"版本管理系统"(VersionControlSystem)。眼下最流行的"版本管理系统",非Git莫属。相比同类软件,Git有很...VincentDriessen提出了一个分支管理的策略,我觉得非常值得借鉴。它可以
主要介绍了浅谈Git分支管理策略,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
26.2.2 Git工作分支和 Subversion 如何对应/ 388 26.2.3 其他辅助文件/ 390 26.3 多样的 git-svn 克隆模式/ 390 26.4 共享 git-svn 的克隆库/ 393 26.5 git-svn 的局限/ 394 第5篇 搭建Git服务器 第27章 使用 HTTP ...
分支策略::shuffle_tracks_button:分支策略! 对于Git!
Git分支策略: 在开始工作之前,请先进入master和git pull ,以确保项目与github保持最新 git checkout -b 'nameOfBranch' 完成工作后git add * git commit -m 'Commit message' git push -u origin '...
第九条 :hammer_and_wrench: 建置状态 :nerd_face: 团队成员介绍部分的GitHub 后端后端前端前端设计设计 :glowing_star: 提交消息约定Git-请参阅“提交消息约定”博客文章并添加一个序言 :cat_face: Git分支策略由于...
删除 Squash 合并的本地 Git 分支 一个节点实用程序,用于删除已经通过压缩合并策略合并到主线中的本地分支。 (经常。) 对于正常的合并提交,您可以运行git branch --merged来获取已合并分支的列表,但是使用 ...
Git分支策略以及如何参与 分支 主机像标签一样进行管理,并按周期(周期)进行分配。 开发分支是分发到开发服务器的分支。 功能分支是开发每个功能的分支。 bugfix分支可以从develop和master分支创建,并且是一个...
Git基础用法 1 一、 Git是什么 1 二、 SVN与Git的最主要的区别 1 三、 安装Git 2 1、 Windows下安装git 2 2、 mac下安装git 2 ...3、 分支管理策略 24 4、Bug处理 26 5、 多人协作 29 五、 git基础命令 33