git分支管理与冲突解决(转载)

Git 分支管理和冲突解决

原文:http://www.cnblogs.com/mengdd/p/3585038.html

创建分支

  git branch

  没有参数,显示本地版本库中所有的本地分支名称。

  当前检出分支的前面会有星号。

  git branch newname

  在当前检出分支上新建分支,名叫newname。

  git checkout newname

  检出分支,即切换到名叫newname的分支。

  git checkout –b newname master

  这个命令将上面两个命令合并:在master分支上创建分支newname分支并检出到该分支。

合并分支间的修改 Merge

  合并操作将两条或多条分支合并到一起,实际上有好几种分支合并方法,下面介绍主要的三种:

  1.直接合并(straight merge)

  把两条分支上的历史轨迹合并,交汇到一起。

  比如要把dev分支上的所有东东合并到master分支:

  首先先到master分支:git checkout master

  然后把dev给合并过来:git merge dev

  注意没参数的情况下merge是fast-forward的,即Git将master分支的指针直接移到dev的最前方。

  换句话说,如果顺着一个分支走下去可以到达另一个分支的话,那么Git在合并两者时,只会简单移动指针,所以这种合并成为快进式(Fast-forward)

  2.压合合并(squashed commits):

  将一条分支上的若干个提交条目压合成一个提交条目,提交到另一条分支的末梢。

  把dev分支上的所有提交压合成主分支上的一个提交,即压合提交:

  git checkout master

  git merge --squash dev

  此时,dev上的所有提交已经合并到当前工作区并暂存,但还没有作为一个提交,可以像其他提交一样,把这个改动提交到版本库中:

  git commit –m “something from dev”

  

  3.拣选合并(cherry-picking):

  拣选另一条分支上的某个提交条目的改动带到当前分支上。

  每一次提交都会产生一个全局唯一的提交名称,利用这个名称就可以进行拣选提交。

  比如在dev上的某个提交叫:321d76f

  把它合并到master中:

  git checkout master

  git cherry-pick 321d76f

  要拣选多个提交,可以给git cherry-pick命令传递-n选项,比如:

  git cherry-pick –n 321d76f

  这样在拣选了这个改动之后,进行暂存而不立即提交,接着可以进行下一个拣选操作,一旦拣选完需要的各个提交,就可以一并提交。

冲突处理

  当两条分支对同一个文件的同一个文本块进行了不同的修改,并试图合并时,Git不能自动合并的,称之为冲突(conflict)。解决冲突需要人工处理。

  比如当前在master分支,想把dev分支merge过来,结果产生了一个冲突,打开文件内容可以看到这么一个冲突:

<<<<<<< HEAD

test in master

=======

test in dev

>>>>>>> dev

  <<<<<<<标记冲突开始,后面跟的是当前分支中的内容。

  HEAD指向当前分支末梢的提交。

  =======之后,>>>>>>>之前是要merge过来的另一条分支上的代码。

  >>>>>>>之后的dev是该分支的名字。

  对于简单的合并,手工编辑,然后去掉这些标记,最后像往常的提交一样先add再commit即可。

删除分支

  有些分支没有必要长期保存,比如分支中的代码已经打了标签并已发布,或者实验分支已经成功完成工作或中途废弃等等。

  注意:打了标签的分支,Git在删除该分支时,从版本树起始到此标签间的全部历史轨迹均会保留,此时删除分支操作只是删除分支本身的名称,因此可以说该分支没有必要长期保存。

  而在其他版本控制工具中,删除分支通常意味着删除分支上的所有历史轨迹,所以不能因为打了标签就认为其没有必要保存。

  删除一个分支dev2:

  git branch –d dev2

  注意不能删除当前所在分支,需要转到别的分支上。

  如果要删除的分支已经成功合并到当前分支,删除分支的操作会直接成功。

  如果要删除的分支没有合并到当前所在分支,则会出现提示,如果确定无须合并而要直接删除,则执行命令:

  git branch –D dev2

  进行强删。

分支重命名

  重命名分支:

  git branch –m oldname newname

  -m不会覆盖已有分支名称,即如果名为newname的分支已经存在,则会提示已经存在了。

  如果改成-M就可以覆盖已有分支名称了,即会强制覆盖名为newname的分支,这种操作要谨慎。

参考资料

  《版本控制之道——使用Git》(Pragmatic Version Control Using Git)

  Git分支管理策略:http://www.ruanyifeng.com/blog/2012/07/git.html

  Git Reference: http://gitref.org/

时间: 2024-10-10 15:38:45

git分支管理与冲突解决(转载)的相关文章

GIT----入门资料,分支管理,冲突解决

最近一直使用者GIT发现使用起来确实很不错,最近做些整理总结,发现了一些很不错的资料,收集在这里,以备忘. GIT入门挺简单的,之前有些过一篇文章,关于GIT的,但是都是一些生硬的操作,并没有系统的学习和使用它.最近的一些经验告诉我,一不要畏惧新事物,只要坚持学习和包容它,不断的突破难点和重点,随着时间的积累,没有不可能发生事情的.这里发现了些很不错的入门资料.猴子都能懂的GIT入门[1]教程,提供了入门,进阶,高级的教程,是一个非常不错的学习教程.还有一个博主写了一个GIT手把手教你使用Git

[廖雪峰] Git 分支管理策略

通常,合并分支时,如果可能,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

GIt分支管理策略

大纲: 1.前言 2.创建分支 3.切换分支 4.合并分支(快速合并) 5.删除分支 6.分支合并冲突 7.合并分支(普通合并) 8.分支管理策略 9.团队多人开发协作 10.总结 注,测试机 CentOS 5.5 x86_64,Git 服务器版本:git version 1.8.2.1,客户端版本:git version 1.9.2.msysgit.0.所有软件请到这里下载:http://msysgit.github.io/. 1.前言 在上一篇博客中我们主要讲解了Git 远程仓库,相信大家对

git 分之合并和冲突解决

Git 分支管理和冲突解决 创建分支 git branch 没有参数,显示本地版本库中所有的本地分支名称. 当前检出分支的前面会有星号. git branch newname 在当前检出分支上新建分支,名叫newname. git checkout newname 检出分支,即切换到名叫newname的分支. git checkout –b newname master 这个命令将上面两个命令合并:在master分支上创建分支newname分支并检出到该分支. 合并分支间的修改 Merge 合并

Github操作与git分支管理

通过今天学习的web新知识和复习Sublime Text的基础知识,让我收获颇多,疑惑也多.尤其是在做用 git 和gitHub来管理自己的代码的题目内容时候遇到了许多的疑问,首先在注册用户时都不太懂,在老师提示和指导下才慢慢理解和完成题目. 了解到git分支管理,感觉这个程序可以给我们带来非常多的便利和快捷.使用的标签也没有很复杂,git程序的操作并不需要网络,而应用到的软件才需要,在团队开发中,遵循一个合理.清晰的开发使用流程是很重要的,不然每人乱写项目会变得难以协调和维护.所以将一个项目文

Git工程开发实践(四)——Git分支管理策略

Git工程开发实践(四)--Git分支管理策略 一.Git版本管理的挑战 Git是非常优秀的版本管理工具,但面对版本管理依然有非常大得挑战.工程开发中,开发者彼此的代码协作必然带来很多问题和挑战:A.如何开始一个Feature开发,而不影响其它Feature?B.由于很容易创建新分支,分支多了如何管理,时间久了,如何知道每个分支是干什么的?C.哪些分支已经合并回了主干?D.如何进行Release的管理?开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时

Git分支管理——创建、合并、删除分支

前言: 几乎所有的版本控制都以某种形式支持分支.使用分支意味着你可以把你的工作从开发主线上分离开来,以免影响开发主线. Git的分支模型成称为它的"必杀技特性",也正因为这一特性,使得Git从众多版本控制系统中脱颖而出.Git处理分支的方式是难以置信的轻量,创建新的分支这一操作是秒级完成的,并且在不同分支之间的切换操作也是一样便捷. Git的分支,其实本质上仅仅是指向提交对象的可变指针.Git的默认分支是master.在多次提交操作之后,其实我们已经有一个指向最后那个提交对象的mast

Git分支管理实战

Git分支管理实战: 使用了Git之后,Git确实比TFS 好用,首先它很轻巧,分支之间切换基本在秒级,分支创建也很方便,但由于方便快捷,最近我们一直在因为分支管理混乱而陷入无穷的痛苦之中, 在此痛定思痛,觉得借鉴网上一个好的方案来管理分支. 一.主分支: 实际开发中,主要存在两条主分支,Master和Develop 分支,这两个分支的生命周期是整个项目周期. 他们有如下特点: 1.Master和develop分支自创建之后都不会删除,会随着项目的增长不断往里面添代码. 2.Master分支是G

[转]Git分支管理策略

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