www.icesr.com
IT运维工程师的摇篮

Git分支管理

Git分支管理

1.分支的作用

分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。 

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

其他版本控制系统如SVN等都有分支管理,但是用过之后你会发现,这些版本控制系统创建和切换分支比蜗牛还慢,简直让人无法忍受,结果分支功能成了摆设,大家都不去用。 

但Git的分支是与众不同的,无论创建、切换和删除分支,Git在1秒钟之内就能完成!无论你的版本库是1个文件还是1万个文件。

2.创建与合并分支

2.1原理介绍

在版本回退里,你已经知道,每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master分支。HEAD严格来说不是指向提交,而是指向mastermaster才是指向提交的,所以,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分支:

真是太神奇了,你看得出来有些提交是通过分支完成的吗?

2.2实践

首先,我们创建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分支上正常提交,比如对test1.txt做个修改,加上一行:

Creating a new branch is quick.

然后提交:

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

$ git checkout master
Switched to branch 'master'

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

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

$ git merge dev
Updating 610c2b0..7d5bd53
Fast-forward
 test1.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

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

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

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

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

Administrator@G3CUWWS80LUWCDG MINGW32 /f/Git/MyGitTest (master)
$ git branch -d dev
Deleted branch dev (was 7d5bd53).

Administrator@G3CUWWS80LUWCDG MINGW32 /f/Git/MyGitTest (master)
$ git branch
* master

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

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

2.3小结

Git鼓励大量使用分支:

查看分支:git branch

创建分支:git branch <name>

切换分支:git checkout <name>

创建+切换分支:git checkout -b <name>

合并某分支到当前分支:git merge<name>

删除分支:git branch -d <name>

3.解决分支合并冲突

人生不如意之事十之八九,合并分支往往也不是一帆风顺的。

准备新的feature1分支,继续我们的新分支开发:

$ git checkout -b feature1
Switched to a new branch &#39;feature1&#39;

修改test1.txt最后一行,改为:

Creating a new branch is quick AND simple.

feature1分支上提交并切换到master分支:

master分支上把test1.txt文件的最后一行改为:

Creating a new branch is quick &amp; simple.

提交:———————————————————–注意提交之前分支还没有合并,只是切换到了主分支

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

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

$ git merge feature1
Auto-merging test1.txt
CONFLICT (content): Merge conflict in test1.txt
Automatic &lt;span style=&quot;font-size:18px;color:#ff0000;&quot;&gt;merge failed&lt;/span&gt;; fix conflicts and then commit the result.

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

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run &quot;git commit&quot;)

Unmerged paths:
  (use &quot;git add &lt;file&gt;...&quot; to mark resolution)

        both modified:   test1.txt
no changes added to commit (use &quot;git add&quot; and/or &quot;git commit -a&quot;)

我们可以直接查看test1.txt的内容:

111111
11111111111
Creating a new branch is quick.
&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD
Creating a new branch is quick &amp; simple.
=======
Creating a new branch is quick AND simple.
&gt;&gt;&gt;&gt;&gt;&gt;&gt; feature1

Git用<<<<<<<=======>>>>>>>标记出不同分支的内容,我们修改如下后保存:

Creating a new branch is quick and simple.

再提交:

Administrator@G3CUWWS80LUWCDG MINGW32 /f/Git/MyGitTest (master|MERGING)
$ git add test1.txt

Administrator@G3CUWWS80LUWCDG MINGW32 /f/Git/MyGitTest (master|MERGING)
$ git commit -m &quot;conflict fixed&quot;
[master 6a36265] conflict fixed

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

最后,删除feature1分支:

$ git branch -d feature1
Deleted branch feature1 (was 26e0710).

工作完成。

做个小结:当Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。用git log –graph命令可以看到分支合并图。

4.分支管理策略

通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息。
如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。
下面我们实战一下–no-ff方式的git merge
首先,仍然创建并切换dev分支:

Administrator@G3CUWWS80LUWCDG MINGW32 /f/Git/MyGitTest (master)
$ git branch
* master

Administrator@G3CUWWS80LUWCDG MINGW32 /f/Git/MyGitTest (master)
$ git checkout -b dev
Switched to a new branch &#39;dev&#39;

修改test1.txt文件,并提交一个新的commit:

Administrator@G3CUWWS80LUWCDG MINGW32 /f/Git/MyGitTest (dev)
$ git add test1.txt

Administrator@G3CUWWS80LUWCDG MINGW32 /f/Git/MyGitTest (dev)
$ git commit -m &quot;add merge&quot;
[dev 47adae6] add merge
 1 file changed, 1 insertion(+)

现在,我们切换回master:

$ git checkout master
Switched to branch &#39;master&#39;

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

Administrator@G3CUWWS80LUWCDG MINGW32 /f/Git/MyGitTest (master)
$ git merge --no-ff -m &quot;merge with no-ff&quot; dev
Merge made by the &#39;recursive&#39; strategy.
 test1.txt | 1 +
 1 file changed, 1 insertion(+)

因为本次合并要创建一个新的commit,所以加上-m参数,把commit描述写进去。
合并后,我们用git log看看分支历史:

在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;
你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。
所以,团队合作的分支看起来就像这样:

小结一下:Git分支十分强大,在团队开发中应该充分应用。合并分支时,加上–no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward合并就看不出来曾经做过合并。

(未完待续)

未经允许不得转载:冰点网络 » Git分支管理

分享到:更多 ()

评论 抢沙发

评论前必须登录!