手记

Git分支和版本回退

一、分支

1、分支简单介绍

简单使用:



可以将git branch new_branchgit checkout new_branch两个命令合并成一个命令: git checkout -b new_branch。这个命令的意思就是创建一个分支并且切换到这个分支上。
本地分支改名: git branch -m 原分支名 新分支名

2、合并分支merge

这个过程中,下一个版本会记录一个parent id,这个parent id就是前一个版本的commit id



注意当我们在dev中更改文件之后,一定要先addcommit,不然那样就会和master内容同步了,我们需要的是在dev中更改之后,在没有进行merge之前,master不会和dev相同: 看下面的演示:



3、快进fast forward

HEAD的含义: (在git reset HEAD test.txt中使用过)

  • HEAD指向的是当前分支;

  • master是指向提交(本质上只的是当前的提交);

即如下表示:



如果我们执行git checkout -b dev,我们就会创建一个dev分支并指向新的分支。

这是在master分支的基础上,但是这个过程并不是像SVN一样会拷贝一份,而是只是创建一个指针dev,会和master指向了同一个提交。但此时HEAD指向的是dev(当前分支)。



查看HEAD文件的内容:



然后我在上图的基础上,如果我在dev分支下进行了一次提交,图就会变成下面这样:



此时master指向第3次提交,而dev已经指向了第四次提交。

接下来,如果我将dev上面的修改合并到master上面 (在master中操作),上面的图就会变成下面这样:



这种情况不会有冲突存在。

实战演示:



总结一下这种情况,就是直接从master分支跳转到了最后的dev修改的那个位置,相当于指针的跳转。

4、master和dev同时修改同一文件同一位置产生冲突

演示冲突:在master中修改了test.txt的第三行,在dev中也修改了test.txt中的第三行,于是合并的时候就会产生冲突:



上面的过程就是如下图的过程:



注意箭头往回指是因为后一个提交里面包含一个parent-id指向前一个提交的commit-id,前面已经说过。

注意观察master分支中test.txt文件的内容以及我们将解决这次冲突(即我们打算保存master的修改而丢弃dev的修改):



5、深入fast-forward模式

也就是说在fast-forward模式下:

  • 如果可能(合并时没有冲突),那么Git就会采用fast-forward模式;

  • 在这种模式下,删除分支时会丢掉分支信息;

  • 合并时加上 -- no-ff参数会禁用fast-forward模式,这样就会多出一个commit - id,也就是说在fast-forward模式下面merge不会多出一个commit-id

git merge -- no-ff dev
  • 查看日志更好的方式

git log --graph

关于fast-forward模式和非fast-forward模式下的少一次commit-id和多一次commid-id的图解:



我们先看使用fast-forward模式下的: (即合并的时候commit-id和另一个分支相同):



再看不使用fast-forward模式:



二、Git版本回退

Git的另外一个强大之处在于可以回退到之前的任意一个版本:



主要看下面的命令:

  • git reset --hard HEAD^, 往后回退1个版本;

  • git reset --hard HEAD~3,往后回退3个版本;

  • git reset --hard commit-id,直接回退到某个commit-id;(如果当前在靠前面,就可以通过git log查看);

  • 如果在后面,不能查看到前面的git log 得到 commit-id怎么办呢?可以用git reflog查看自己的操作日志;

实战演示:



查看修改和提交日志:



下面演示怎么回退:


原文:Java架构笔记


0人推荐
随时随地看视频
慕课网APP