http://blog.csdn.net/pipisorry/article/details/46958699
分支的意义
创建分支可以避免提交代码后对主分支的影响,同时也使你有了相对独立的开发环境。

假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。

分支管理使用基本命令

创建并切换到新分支

git checkout -b new_branch

新建分支

git branch new_branch

查看当前分支

git branch
切换到master分支

(dev): git checkout master

Note: 切换分支后你会发现本地文件会变化,如果dev分支和master文件不同的话。再cheout回来就又可以看到之前分支的文件了。不过git2.0以上好像都看得到文件。

在dev分支中时,可以通过git pull origin master将master分支上的文件下载到本地当前分支中。
合并分支到当前分支

git merge命令用于合并指定分支到当前分支
把dev分支的工作成果合并到master分支上:

$(master): git merge dev

合并分支的操作是从new_branch合并到master分支(这时master的内容就变成了dev的内容),当前环境在master分支。
删除分支

git branch -d new_branch

皮皮Blog

git分支使用

每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master分支。HEAD严格来说不是指向提交,而是指向master,master才是指向提交的,所以,HEAD指向的就是当前分支。

一开始的时候,master分支是一条线,Git用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点:

每次提交,master分支都会向前移动一步,这样,随着你不断提交,master分支的线也越来越长。

当我们创建新的分支,例如dev时,Git新建了一个指针叫dev,指向master相同的提交,再把HEAD指向dev,就表示当前分支在dev上:

Git创建一个分支很快,因为除了增加一个dev指针,改改HEAD的指向!

不过,从现在开始,对工作区的修改和提交就是针对dev分支了,比如新提交一次后,dev指针往前移动一步,而master指针不变:

假如我们在dev上的工作完成了,就可以把dev合并到master上。Git怎么合并呢?最简单的方法,就是直接把master指向dev的当前提交,就完成了合并:

所以Git合并分支也很快,就改改指。

合并完分支后,甚至可以删除dev分支。删除dev分支就是把dev指针给删掉,删掉后,我们就剩下了一条master分支:

git分支管理实战

首先,我们创建dev分支,然后切换到dev分支:

$ git checkout -b dev
Switched to a new branch 'dev'

git checkout命令加上-b参数表示创建并切换,相当于以下两条命令:

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

然后,用git branch命令查看当前分支:

$ git branch
* dev
  master

git branch命令会列出所有分支,当前分支前面会标一个*号。

然后,我们就可以在dev分支上正常提交,比如对readme.txt做个修改,加上一行:

Creating a new branch is quick.

然后提交:

$ git add readme.txt
$ git commit -m "branch test"
[dev fec145a] branch test
 1 file changed, 1 insertion(+)

现在,dev分支的工作完成,我们就可以切换回master分支:

$ git checkout master
Switched to branch 'master'

切换回master分支后,再查看一个readme.txt文件,刚才添加的内容不见了!因为那个提交是在dev分支上,而master分支此刻的提交点并没有变:

现在,我们把dev分支的工作成果合并到master分支上:(这一般是从dev分支上提交一个版本如1.0到master主分支上,这样master分支和dev分支的内容一样了)

$ git merge dev
Updating d17efd8..fec145a
Fast-forward
 readme.txt |    1 +
 1 file changed, 1 insertion(+)

git merge命令用于合并指定分支到当前分支。合并后,再查看readme.txt的内容,就可以看到,和dev分支的最新提交是完全一样的。

注意到上面的Fast-forward信息,Git告诉我们,这次合并是“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度非常快。

当然,也不是每次合并都能Fast-forward,我们后面会将其他方式的合并。

合并完成后,就可以放心地删除dev分支了:

$ git branch -d dev
Deleted branch dev (was fec145a).

删除后,查看branch,就只剩下master分支了:

$ git branch
* master

因为创建、合并和删除分支非常快,所以Git鼓励你使用分支完成某个任务,合并后再删掉分支,这和直接在master分支上工作效果是一样的,但过程更安全。

[创建与合并分支]

皮皮Blog

分支管理策略

通常,合并分支时,如果可能,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 add readme.txt
$ git commit -m "add merge"
[dev 6224937] add merge
 1 file changed, 1 insertion(+)

现在,我们切换回master:

$ git checkout master
Switched to branch 'master'

准备合并dev分支,请注意--no-ff参数,表示禁用Fast forward:

$ git merge --no-ff -m "merge 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
*   7825a50 merge with no-ff
|\
| * 6224937 add merge
|/
*   59bc1cb conflict fixed
...

可以看到,不使用Fast forward模式,merge后就像这样:

实际开发中分支管理的几个基本原则

首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;

那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;

你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。

所以,团队合作的分支看起来就像这样:

[分支管理策略]

写保护分支

Github推出了“可以写保护的分支”,对多人协作的项目非常有用:不得删除、不得强行推送、只有测试全部通过才接受PR

[About protected branches]

from:http://blog.csdn.net/pipisorry/article/details/46958699

ref:learnGitBranching-demo

Git版本控制:Git分支处理的更多相关文章

  1. Git版本控制 Git、github,gitlab相关操作

    目录 关于版本控制 版本管理工具 集中式管理 分布式管理 git版本管理 git介绍 软件安装 Git工作状态 原理流程步骤 git基本操作 对文件进行修改 分支 共享仓库 创建共享仓库: 共享仓库上 ...

  2. GIT版本控制 — GIT与SVN的相互转换 (三)

    git-svn git-svn用于Git和SVN的转换,可以把Git仓库迁移成SVN仓库,反之亦可. 详细介绍可见[1],或者命令行输入git-svn. Bidirectional operation ...

  3. 版本控制git(三)-git分支

    通过本系列的上两篇文章(查看系列文章:http://www.cnblogs.com/jerehedu/p/4607599.html#bbkz),我们已经知道了如何使用Git完成对文件的版本控制.本次我 ...

  4. 第二篇:版本控制git之分支

    有人把 Git 的分支模型称为它的`‘必杀技特性’',也正因为这一特性,使得 Git 从众多版本控制系统中脱颖而出. 为何 Git 的分支模型如此出众呢? Git 处理分支的方式可谓是难以置信的轻量, ...

  5. 版本控制git之三-多人协作 变基 推送 拉取 删除远程分支

      版本控制git之三-多人协作 wangfeng7399已关注0人评论350人阅读2019-02-20 21:33:08   如果你想获得一份已经存在了的 Git 仓库的拷贝,比如说,你想为某个开源 ...

  6. 版本控制git之二 分支 切换分支 创建分支 合并 删除

      版本控制git之二 分支   有人把 Git 的分支模型称为它的`‘必杀技特性’',也正因为这一特性,使得 Git 从众多版本控制系统中脱颖而出. 为何 Git 的分支模型如此出众呢? Git 处 ...

  7. 版本控制git之二-分支

    有人把 Git 的分支模型称为它的`‘必杀技特性’',也正因为这一特性,使得 Git 从众多版本控制系统中脱颖而出. 为何 Git 的分支模型如此出众呢? Git 处理分支的方式可谓是难以置信的轻量, ...

  8. 2,版本控制git --分支

    有人把 Git 的分支模型称为它的`‘必杀技特性’',也正因为这一特性,使得 Git 从众多版本控制系统中脱颖而出. 为何 Git 的分支模型如此出众呢? Git 处理分支的方式可谓是难以置信的轻量, ...

  9. 版本控制-Git服务器搭建和常用命令使用

    Git是目前世界上最先进的分布式版本控制系统(没有之一).使用Svn的请参考<版本控制-svn服务器搭建和常用命令(centos 6.3)>,下面介绍Git的常用命令 常用命令 简单版 升 ...

随机推荐

  1. MacOS下安装rvm的几点注意

    如果用以下链接无法下载的话: curl -sSL https://get.rvm.io | bash -s stable #或者 curl -L https://rvm.io | bash -s st ...

  2. lucene全文检索基础

    全文检索是一种将文件中所有文本与检索项匹配的文字资料检索方法.比如用户在n个小说文档中检索某个关键词,那么所有包含该关键词的文档都返回给用户.那么应该从哪里入手去实现一个全文检索系统?相信大家都听说过 ...

  3. 激活第一个CPU

    回到start_kernel,559行,boot_cpu_init函数,跟start_kernel位于同一文件: 494static void __init boot_cpu_init(void) 4 ...

  4. Android开发学习之路--基于vitamio的视频播放器(二)

      终于把该忙的事情都忙得差不多了,接下来又可以开始good good study,day day up了.在Android开发学习之路–基于vitamio的视频播放器(一)中,主要讲了播放器的界面的 ...

  5. linux 服务器网络有关的内核参数

    几乎所有的内核模块,包括内核核心模块和驱动程序,都在/proc/sys 文件系统下提供了某些配置文件以提供用户调整模块的属性和行为.通常一个配置文件对应一个内核参数,文件名就是参数的名字,文件的内容是 ...

  6. 生活沉思录 via 哲理小故事

    本文转载:http://www.cnblogs.com/willick/p/3174803.html 1.小托蒂的悲剧 意大利小男孩托蒂,有一只十分奇怪的眼睛,因为从生理上看,这是一只完全正常的眼睛, ...

  7. Android优化之ViewPager的懒加载

    转载本博客请注明出处:点击打开链接    http://blog.csdn.net/qq_32059827/article/details/52487794 出于对用户消耗流量的考虑,有必要对view ...

  8. 【java虚拟机系列】从java虚拟机字节码执行引擎的执行过程来彻底理解java的多态性

    我们知道面向对象语言的三大特点之一就是多态性,而java作为一种面向对象的语言,自然也满足多态性,我们也知道java中的多态包括重载与重写,我们也知道在C++中动态多态是通过虚函数来实现的,而虚函数是 ...

  9. Centos6.6上源码安装Nodejs V4版本

    本来就是想在vps上装一个Ghost博客,这个博客依赖的是Nodejs,然后推荐的是V4版本.然后我就对着官网的步骤安装,发现根本没有Centos6 i386的资源了(64位的还是有的), 我只能在那 ...

  10. Mybatis3.4.0不支持mybatis-spring1.2.5及以下版本

    今天将工程的Mybatis的版本由3.3.0升级到3.4.0导致程序运行错误,使用的mybatis-spring版本是1.2.3,错误内容如下,最后发现是SpringManagedTransactio ...