自学git心得-3

时间:2024-01-19 16:20:32

转眼到第三节了,我们进入分支管理。

git领域里的分支可以理解为一个有安全保障的临时仓库,有时我们新修改了代码,突然发现有bug需要回到之前的版本,有时我们开发到一半,突然要出去一趟,如何安全保存当前代码成为了一

个痛点,这时候有个分支就ok了,我们每次修改代码都新建一个分支,在上面修改完了再与之前的版本合并,而原来的版本可以保存也可以合并,而中途有事也可以用stash命令进行保存。

接下来我们具体学习:

之前我们学过版本回退,每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master分支。HEAD严格来说不是

指向提交,而是指向mastermaster才是指向提交的,所以,HEAD指向的就是当前分支。一开始的时候,master分支是一条线,Git用master指向最新的提交,再用HEAD指向master,就能确

定当前分支,HEAD其实就可以理解成C里面的二级指针。每次提交,master分支都会向前移动一步,这样,随着我们不断提交,master分支的线也越来越长。当我们创建新的分支,例如dev

,Git就新建一个指针叫dev,指向master相同的提交,再把HEAD指向dev,就表示当前分支在dev上。那么从现在开始,对工作区的修改和提交就是针对dev分支了,比如新提交一次后,dev

针往前移动一步,而master指针不变,这就实现了旧版本的保存,当我们完成dev上的工作并确定无误了,我们就可以将master与其合并,此时dev就完成了它的使命,我们可以删除它,于是我

们又只剩下master一个分支了。

值得一提的是,上述一切操作都是基于指针层面的,没有对文件进行修改,这是分支的一大亮点。(参考链接有详细的图解)

接下来具体上命令:

1.创建并切换至分支dev: git checkout -b dev

2.查看当前分支: git branch  (会列出所有分支,当前分支前面会标一个*号)

3.在分支dev上修改并提交文件: git add readme.txt  &  git commit -m "branch test"

4.切换回master分支: git checkout master (注意此时打开readme.txt本地文件是看不到刚刚在dev上的修改的)

5.把dev上的工作结果合并到master上: git merge dev

6.删除dev分支: git branch -d dev

然而使用分支也不总是一帆风顺的,这里以合并分支时的冲突问题为例。

假设我们现在分别在master和feature1两个分支上都有了新的提交,就像这样:

自学git心得-3(截图来自廖雪峰官方网站,下同)

显然现在master和feature1两个分支处于平行的关系,如果用命令git merge feature1合并二者则会发生冲突,打开readme.txt我们就可以看到了。

我们现在来解决冲突:

首先我们将readme.txt编辑成我们理想的样子,然后进行提交(注意是两步,先add后commit),于是现在的情况变成了这样:

自学git心得-3(也可以用命令git log查看分支情况,只是bash上的图没有这个截图清晰)

最后我们删除feature1就OK了~

这是一种典型的手动解决冲突问题的情况,注意一定要解决好冲突问题再合并。

上述所有提到的合并其实都是一种强制快速合并(Fast forward),也就是说用master强制合并当前的dev分支,也就是说分支dev同时被删除了,你可能会说,master合并过来不也就和dev

一样的吗为什么不删掉dev呢,事实上,重要的不是dev所指的文件内容,而是它的分支信息,如何能做到保留它呢,我们用命令git merge --no-ff -m "merge with no-ff" dev 来合并dev就行

了,就像这样:

自学git心得-3

在团队工程中,每个人写完了自己的代码就会合并到团队工程中去,这种情况下,用保留当前分支的合并方法就显得十分重要了,假如之后发现了问题,你可以很轻松地回溯,查看bug的来源。

这一节内容有点太多了233,先歇会,下一节咱们从应用分支继续~