git学习笔记三

分支是git中非常重要的一块,同时在我们开发过程中对我们团队开发起到了很大的作用。

那么何为分支?在我们开发中是如何使用分支的?

一、分支的概述

假设你准备开发一个新的功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没有写完,不完整的代码库可能会导致别人干不了活。如果等代码全部写完再一次性提交,没有写完只能先暂时保存在本地仓库中。这样存在丢失每天进度的巨大风险。

现在有了分支,就不用怕了。你创建一个属于自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,在一次性合并到原来的分支上,这样,即安全,有不影响别人工作。

可见使用分支的目的就是可以把你的工作从开发主线上分离开来,以免影响开发主线。

其他很多版本控制系统中都有某种形式支持的分支。但是这些系统对分支这一块的实现不是很好(几乎是完全创建一个源码目录的副本),效率极其低。

git中的分支很轻,创建一个新的分支是瞬间可以完成的事情,不同分支之间的切换也是非常便捷的。所以很多开发者在使用git进行版本控制的时候是很愿意去使用分支的。

git中的分支是如何实现的呢?下面就介绍一下其中的基本流程。

1、Git中分支的实现

我们知道git保存的不是文件的变化或者差异,而是一系列不同时刻的文件快照。在进行提交时,git会保存一个提交对象(git学习笔记一中有提到)。这个提交对象包含了很多的信息,其中就有一个指向暂存区内容快照的指针。首次提交产生的提交对象没有父对象,普通提交操作产生的提交会有父对象,由多个分支合并产生的提交对象有多个父对象。

git分支,其实仅仅是指向提交对象的可变指针,git的默认分支名是master。在多次提交操作之后,你其实已经有一个指向最后那个提交对象的master分支了。它会在每次体积哦啊操作中自动向前移动。

git的“master”分支并不是一个特殊分支,它和其他分支完全没有区别。之所以几乎每个仓库都有master分支,是因为git init命令默认创建了它并且大多数人都懒得改动它。

通俗的讲,我们可以把分支理解成时间轴,在没有创建任何分支的时候我们只有一个分支即master主分支,master指向提交,HEAD指向的是master(指向当前分支)。每次提交后,master分支都会往下走一步。提交的次数越多,这个时间轴就会越长。

二、创建分支与切换分支

1.创建一个分支,但是仍然停留在当前分支

git branch [branch-name][commit]*

创建一个分支dev01,可以把dev01看成一个指针,指向master相同的提交,但是HEAD现在还是指向master,表示当前所在的分支还是master分支。

新建分支时,可以指向指定的commit使用命令:

git branch branch-name commitID

2、新建一个分支并切换到这个新建的分支

git checkout -b dev

创建一个分支dev,改变HEAD的指向,工作区中的文件并没有发生任何改变。不过从现在开始,对工作区的修改和提交就是针对dev分支的,比如新提交一次后,dev的指针往前移动一步,而master指针不变。

3.只切换分支

git checkout [branch-name]

切换到指定分支,并更新工作区git checkout -

切换到上一个分支

4、新建一个分支与远程分支简历追踪关系

git branch --track [branch] [remote-branch]

关于与远程分支,现在不展开讲了,后面会在远程仓库中介绍

三、查看分支

git branch:列出所有本地分支

git branch -r:列出所有远程分支

git branch -a:列出所有本地和远程分支

四、分支合并

git merge [branch]

合并指定分支到当前分支。

比如我们创建了一个新的分支dev,并且切换到当前分支。在当前分支中我们对a。txt进行了修改。当我们切换回master分之后,再查看a.txt文件,才发现刚才修改的内容不见了。

因为刚才的提交是在dev分支上,而master分支此刻的提交并没有改变:

现在,我们把dev分支的工作成果合并到master分支上:

注意在合并分支的时候先要切换到master分支上。因为git merge命令合并指定分支到当前分支。合并后,再查看a.txt的内容,就可以看到和dev分支的最新提交是完全一样的。

注意到上面的Fast-forward信息,表示这次合并时“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度非常快。(不是每次合并都是这种模式)。其他的方式我们后面再说。

合并完之后我们就可以放心地删除dev分支了。

git branch -d dev

删除之后就只剩下master分支了

五、解决冲突

如果同一个文件在合并分支时都被修改了则会引起冲突。

下面借鉴阮一峰老师的例子,说一些如何解决冲突。

先准备一个新dev分支:

修改a.txt的内容,改为:“a hello second”

在dev分支上提交:

切换到master分支上:

在master分支上把a.txt文件中的内容修改一下:“a hello thrid”

在master上提交:

现在,master分支和dev分支各自都分别有新的提交,变成了这样:

这种情况下,git无法执行“快速合并”,只能试图把各自修改合并起来,但这种合并就可能会有冲突,我们试试看:

果然冲突了,git显示a.txt文件存在冲突,必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件:

我们可以直接查看a.txt文件的内容:

Git用>>>>>>标记出不同分支的内容我们修改如下后保存:“a hello thrid”

再提交:

现在,master分支和dev分支变成如下:

用带参数的git log也可以看到分支的合并的情况:

最后,删除dev分支:

小结:当git无法自动合并分支时,就必须首先解决冲突,解决冲突之后,再提交,合并完成。

用git log --graph命令可以看到分支合并图。

六、git rebase

(1)、基本

rebase(变基)用于把一个分支的修改合并到当前分支。

假设你现在基于master分支,创建了一个mywork分支。

假设master分支上已经有两个提交了。如图:

现在我们在这个分支上做一些修改,然后生成两个提交。

但是与此同时,有人也在master上进行了一些修改并且做了提交,这就意味着master和mywork这两个分支各自“前进”了,它们之间“分叉”了。

在这里你可以通过merge命令将mywork与master分支进行合并。如图:

但是,如果你想让mywork分支历史看起来像没有经历过任何合并一样,你也许可以使用git rebase:

这些命令会把你的mywork分支里的每个提交(commit)取消掉,并且把它们临时保存为补丁(patch)(这些补丁被放到.git/rebase目录中),然后把mywork分支更新为最新的master分支,最后把保存的这些补丁应用到mywork分支上。

当mywork分支更新之后,它会指向这些新创建的提交,而那些老的提交会别丢弃。如果运行垃圾收集命令(git gc)这些丢失的提交就会删除。

(2) git rebase -i

用-i标记运行git rebase开始交互式rebase。交互rebase给你在合并过程中修改单个提交的机会,而不是盲目地将所有提交都移到新的基上。你可以删除,分割提交,更改提交的顺序。它就像是打了鸡血的git commit --amend一样。

用法

将当前分支rebase到base上,但是使用可交互的形式。它会打开一个编辑器,你可以为每个将要reabse放入提交输入命令。这些命令决定了每个提交将会怎样被转移到新的基上去。你还可以对这些提交进行排序。

交互式rebase给了你控制项目历史的完全掌握。它给了开发人员很大的自由,因为它可以提交一个混乱的历史,开发人员只需专注于写代码,然后回去恢复干净。

大多数开发者喜欢在并入住代码库之前用交互式rebase来完善他们的feature分支。他们可以将不重要的提交合并在一起,删除不需要的,确保所有东西在提交到正式项目历史前是整齐的。

例子:

最后那个命令会打开一个编辑器,包含mywork的两个提交,和一些提示:

保存并关闭编辑器开始rebase。两一个编辑器打开,询问你合并后的快照的提交信息。在定义了提交信息之后,rebase就完成了,你可以在git log输出中看到那个提交。整个过程可以用下图可视化。

注意缩并的提交和原来两个提交的ID都不一样,告诉我们这确实是一个新的提交。最后,你可以执行一个快速向前的合并,来将完善的mywork分支整合进主代码库。

(4)、解决冲突

在rebase的过程中,也许会出现冲突,在这种情况下git会停止rebase并会让你去解决冲突;在解决冲突后,用“git add”,命令去更新这些内容的索引,然后你无需执行git commit,只要执行git rebase --continue,这样git会继续应用余下的补丁。

在任何时候,你可以用--abort参数来终止rebase的行动,并且mywork分支会回到rebase开始前的状态。

(5)、git rebase和git merge的区别

现在我们可以看一下用合并merge和rebase所产生的历史区别:

当我们使用git log来参看commit时,其commit的顺序也有所不同。

假设C3提交于9:00AM,C5提交于10:00AM,C4提交于11:00AM,C6提交于12:00AM,对于使用git merge来合并所看到的commit的顺序(从新到旧)是:C7,C6,C4,C5,C3,C2,C1

对于使用git rebase来合并所看到的commit的顺序(从新到旧)是:C7,C6',C5',C4,C3,C2,C1

因为C6'提交知识C6提交的克隆,C5'提交只是C5提交的克隆。

从用户的角度来看使用git rebase来合并后所看到的commit的顺序(从新到旧)是:C7,C6,C5,C4,C3,C2,C1

另外,我们在使用git pull命令的时候,可以使用--rebase参数,即git pull --rebase,这里表示把你的本地当前分支里的每个提交(commit)取消掉,并且把它们临时保存为补丁(patch,这些补丁放到“。“.git/rebase”目录中),然后把本地当前分支更新为最新的“origin”分支,最后把保存的这些补丁应用到本地当前分支上。

(6)、git reflog

如果在回退以后又想再次回到之前的版本,git reflog可以查看所有分支的所有操作记录(包括commit和reset的操作),包括已经删除的commit记录,git log则不能查看已经删除的commit记录。

如下图所示:

引用日志只对提交到本地仓库的更改有效,而且只有移动操作会被记录。

七、分支管理策略

master主分支应该是非常稳定,用来发布新版本,一般情况下不允许在上面工作,工作一般情况下在新建的dev分支上工作,工作完后,dev分支代码稳定后就可以合并到主分支master上了。

接下来我们会介绍git中的远程仓库。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180417G1Q9H500?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

同媒体快讯

扫码关注云+社区

领取腾讯云代金券