Git基础篇（六）——Git版本回退

前言：
  人无完人，没有人能确保每次的修改都是完美的，即使提交是完美的需求也可能突然改变。版本回退是Git中重要且常用的操作之一。

1 Git版本回退

  说到版本回退首先要知道Git是如何标识不同版本的。Git会为每次提交上去的版本记录快照并生成一串十六进制编号（Hash值），以这串编号作为当前版本的独一无二标识，按照时间线多次的提交就连成条”线“也即提交记录，每一条”线“就是一个分支，还存在一个HEAD指针指向其中一个版本也即其记录了某个版本的十六进制编号。原理就像数据结构中链表和节点指针的关系。

commit 6574ac2446b82c86f2af107783b405032784303a
Author: onlycalm <741089410@qq.com>
Date:   Fri Feb 12 00:05:22 2021 +0800

Git基础篇（六）——Git版本回退

前言：
  人无完人，没有人能确保每次的修改都是完美的，即使提交是完美的需求也可能突然改变。版本回退是Git中重要且常用的操作之一。

1 Git版本回退

  说到版本回退首先要知道Git是如何标识不同版本的。Git会为每次提交上去的版本记录快照并生成一串十六进制编号（Hash值），以这串编号作为当前版本的独一无二标识，按照时间线多次的提交就连成条”线“也即提交记录，每一条”线“就是一个分支，还存在一个HEAD指针指向其中一个版本也即其记录了某个版本的十六进制编号。原理就像数据结构中链表和节点指针的关系。

commit 6574ac2446b82c86f2af107783b405032784303a
Author: onlycalm <741089410@qq.com>
Date:   Fri Feb 12 00:05:22 2021 +0800

  回退的目的是在旧版本基础上修改并重新提交，这个过程可以分为两步，第一步是版本回退到旧版本也即版本提交的回退，第二步是将旧的版本记录重新回到进行开发的工作目录下来也即工作区之间的提交回退，实际操作中这两步也可以只用一条指令。

1.1 工作区之间的提交回退

  在前面的文章中我们提到Git中将存储分为四种区域，如果将这个提交顺序称为正向提交，工作目录->暂存区->仓库区->远程仓库 ，那么顺序反过来就是版本提交回退了。

1.1.1 仓库区回退到工作目录

1.1.1.1 git checkout

  git checkout指令可以将本地仓库的指定提交记录检出到工作目录。<commit>可以是对应版本的Hash编号或标签，Hash编号可以写完整的，一般写前7位即可。

git checkout <commit>

  放弃工作区当前的修改，强制检出仓库区当前版本。不过该指令要慎用，因为没有“后悔”指令，一旦放弃工作目录的修改就无法找回，因为这些修改还未被Git管理。

git checkout -f

1.1.2 远程仓库区回退到本地仓库

  由于远程仓库可能是多人共同维护的，因此从远程仓库过来的更新可能是自己历史提交的记录也可能是别人提交的记录。

1.1.2.1 git fetch

  当指定远程主机某个分支时，只对指定的分支有效，拉取该远程主机下某分支的全部更新内容到本地仓库。

git fetch origin master

  将远程仓库的特定主机全部更新内容拉取到本地仓库。只指定远程主机名，不特指某个分支，则对所有分支都有效。

git fetch origin

  如果所操作的仓库只有一个远程主机和分支，连主机名都可省略。

git fetch

1.1.2.2 git clone

  将远程仓库整个克隆到本地某个目录。<Address是远程仓库的地址。

git clone <Address>

1.1.3 远程仓库区回退到工作目录

  将远程仓库内容直接拉取的到工作空间常见的指令是git pull，与git fetch相比除了拉取的目标存储区域不同外，pull拉取后会将远程库和本地分支合并（merge），而合并可能存在冲突需要我们手动解决，因此它是拉取到工作目录，解决冲突后commit。

1.1.3.1 git pull

  将远程主机的全部更新内容拉取到本地并且和本地存在追踪关系的分支进行合并。

git pull origin

  如果所操作的仓库只有一个远程主机和分支，连主机名都可省略。

git pull

1.2 提交版本的回退

1.2.1 git reset

  将本地仓库的版本回退到上一次提交的版本。一个^表示上一个提交版本，如果连续写N个^则会回退到前第N次提交。git reset版本回退后，中间“跨过”的版本会直接删除，因为有版本丢弃所以HEAD将会“断”，不是在原来基础上增加，所以要慎用。

git reset HEAD^

  回退版本时可以直接指定版本的Hash值或标签。

git reset <commit>

  但如果要回退的历史版本比较久远，写很多个^会很麻烦，也可以使用~<N>回退前第N次提交。比如以下指令表示回退到前第5次提交。

git reset HEAD~5

  使用--soft指令，可以撤销对本地仓库的提交将版本回退到历史版本，但不影响工作目录和暂存区未完成的修改。也即只回退版本库，但不影响暂存区和工作区。

git reset --soft HEAD^

  使用--mixed指令，回退版本库和暂存区，实际上--mixed可以被省略，也就是默认情况下的git reset指令。

git reset --mixed HEAD^

  使用--hard指令，回退版本库、暂存区、工作区。用这个指令要小心，因为工作区的修改是没有版本控制的，一旦工作区的修改没了是无法恢复的。

git reset --hard HEAD^

1.2.2 git revert

  git revert特殊之处在于其回退版本后中间“跨过”的版本也都会保留，并且HEAD也会在原来基础上增加，也即不影响之前的提交内容。指令用法与git reset是类似的。

git revert HEAD^^

git revert HEAD~5

  回退版本时可以直接指定版本的Hash编号或标签。

git revert <commit>

  回退的目的是在旧版本基础上修改并重新提交，这个过程可以分为两步，第一步是版本回退到旧版本也即版本提交的回退，第二步是将旧的版本记录重新回到进行开发的工作目录下来也即工作区之间的提交回退，实际操作中这两步也可以只用一条指令。

Git基础篇（六）——Git版本回退

前言：
  人无完人，没有人能确保每次的修改都是完美的，即使提交是完美的需求也可能突然改变。版本回退是Git中重要且常用的操作之一。

1 Git版本回退

  说到版本回退首先要知道Git是如何标识不同版本的。Git会为每次提交上去的版本记录快照并生成一串十六进制编号（Hash值），以这串编号作为当前版本的独一无二标识，按照时间线多次的提交就连成条”线“也即提交记录，每一条”线“就是一个分支，还存在一个HEAD指针指向其中一个版本也即其记录了某个版本的十六进制编号。原理就像数据结构中链表和节点指针的关系。

commit 6574ac2446b82c86f2af107783b405032784303a
Author: onlycalm <741089410@qq.com>
Date:   Fri Feb 12 00:05:22 2021 +0800

  回退的目的是在旧版本基础上修改并重新提交，这个过程可以分为两步，第一步是版本回退到旧版本也即版本提交的回退，第二步是将旧的版本记录重新回到进行开发的工作目录下来也即工作区之间的提交回退，实际操作中这两步也可以只用一条指令。

1.1 工作区之间的提交回退

  在前面的文章中我们提到Git中将存储分为四种区域，如果将这个提交顺序称为正向提交，工作目录->暂存区->仓库区->远程仓库 ，那么顺序反过来就是版本提交回退了。

1.1.1 仓库区回退到工作目录

1.1.1.1 git checkout

  git checkout指令可以将本地仓库的指定提交记录检出到工作目录。<commit>可以是对应版本的Hash编号或标签，Hash编号可以写完整的，一般写前7位即可。

git checkout <commit>

  放弃工作区当前的修改，强制检出仓库区当前版本。不过该指令要慎用，因为没有“后悔”指令，一旦放弃工作目录的修改就无法找回，因为这些修改还未被Git管理。

git checkout -f

1.1.2 远程仓库区回退到本地仓库

  由于远程仓库可能是多人共同维护的，因此从远程仓库过来的更新可能是自己历史提交的记录也可能是别人提交的记录。

1.1.2.1 git fetch

  当指定远程主机某个分支时，只对指定的分支有效，拉取该远程主机下某分支的全部更新内容到本地仓库。

git fetch origin master

  将远程仓库的特定主机全部更新内容拉取到本地仓库。只指定远程主机名，不特指某个分支，则对所有分支都有效。

git fetch origin

  如果所操作的仓库只有一个远程主机和分支，连主机名都可省略。

git fetch

1.1.2.2 git clone

  将远程仓库整个克隆到本地某个目录。<Address是远程仓库的地址。

git clone <Address>

1.1.3 远程仓库区回退到工作目录

  将远程仓库内容直接拉取的到工作空间常见的指令是git pull，与git fetch相比除了拉取的目标存储区域不同外，pull拉取后会将远程库和本地分支合并（merge），而合并可能存在冲突需要我们手动解决，因此它是拉取到工作目录，解决冲突后commit。

1.1.3.1 git pull

  将远程主机的全部更新内容拉取到本地并且和本地存在追踪关系的分支进行合并。

git pull origin

  如果所操作的仓库只有一个远程主机和分支，连主机名都可省略。

git pull

1.2 提交版本的回退

1.2.1 git reset

  将本地仓库的版本回退到上一次提交的版本。一个^表示上一个提交版本，如果连续写N个^则会回退到前第N次提交。git reset版本回退后，中间“跨过”的版本会直接删除，因为有版本丢弃所以HEAD将会“断”，不是在原来基础上增加，所以要慎用。

git reset HEAD^

  回退版本时可以直接指定版本的Hash值或标签。

git reset <commit>

  但如果要回退的历史版本比较久远，写很多个^会很麻烦，也可以使用~<N>回退前第N次提交。比如以下指令表示回退到前第5次提交。

git reset HEAD~5

  使用--soft指令，可以撤销对本地仓库的提交将版本回退到历史版本，但不影响工作目录和暂存区未完成的修改。也即只回退版本库，但不影响暂存区和工作区。

git reset --soft HEAD^

  使用--mixed指令，回退版本库和暂存区，实际上--mixed可以被省略，也就是默认情况下的git reset指令。

git reset --mixed HEAD^

  使用--hard指令，回退版本库、暂存区、工作区。用这个指令要小心，因为工作区的修改是没有版本控制的，一旦工作区的修改没了是无法恢复的。

git reset --hard HEAD^

1.2.2 git revert

  git revert特殊之处在于其回退版本后中间“跨过”的版本也都会保留，并且HEAD也会在原来基础上增加，也即不影响之前的提交内容。指令用法与git reset是类似的。

git revert HEAD^^

git revert HEAD~5

  回退版本时可以直接指定版本的Hash编号或标签。

git revert <commit>

1.1 工作区之间的提交回退

  在前面的文章中我们提到Git中将存储分为四种区域，如果将这个提交顺序称为正向提交，工作目录->暂存区->仓库区->远程仓库 ，那么顺序反过来就是版本提交回退了。

1.1.1 仓库区回退到工作目录

1.1.1.1 git checkout

  git checkout指令可以将本地仓库的指定提交记录检出到工作目录。<commit>可以是对应版本的Hash编号或标签，Hash编号可以写完整的，一般写前7位即可。

git checkout <commit>

  放弃工作区当前的修改，强制检出仓库区当前版本。不过该指令要慎用，因为没有“后悔”指令，一旦放弃工作目录的修改就无法找回，因为这些修改还未被Git管理。

git checkout -f

1.1.2 远程仓库区回退到本地仓库

  由于远程仓库可能是多人共同维护的，因此从远程仓库过来的更新可能是自己历史提交的记录也可能是别人提交的记录。

1.1.2.1 git fetch

  当指定远程主机某个分支时，只对指定的分支有效，拉取该远程主机下某分支的全部更新内容到本地仓库。

git fetch origin master

  将远程仓库的特定主机全部更新内容拉取到本地仓库。只指定远程主机名，不特指某个分支，则对所有分支都有效。

git fetch origin

  如果所操作的仓库只有一个远程主机和分支，连主机名都可省略。

git fetch

1.1.2.2 git clone

  将远程仓库整个克隆到本地某个目录。<Address是远程仓库的地址。

git clone <Address>

1.1.3 远程仓库区回退到工作目录

  将远程仓库内容直接拉取的到工作空间常见的指令是git pull，与git fetch相比除了拉取的目标存储区域不同外，pull拉取后会将远程库和本地分支合并（merge），而合并可能存在冲突需要我们手动解决，因此它是拉取到工作目录，解决冲突后commit。

1.1.3.1 git pull

  将远程主机的全部更新内容拉取到本地并且和本地存在追踪关系的分支进行合并。

git pull origin

  如果所操作的仓库只有一个远程主机和分支，连主机名都可省略。

git pull

1.2 提交版本的回退

1.2.1 git reset

  将本地仓库的版本回退到上一次提交的版本。一个^表示上一个提交版本，如果连续写N个^则会回退到前第N次提交。git reset版本回退后，中间“跨过”的版本会直接删除，因为有版本丢弃所以HEAD将会“断”，不是在原来基础上增加，所以要慎用。

git reset HEAD^

  回退版本时可以直接指定版本的Hash值或标签。

git reset <commit>

  但如果要回退的历史版本比较久远，写很多个^会很麻烦，也可以使用~<N>回退前第N次提交。比如以下指令表示回退到前第5次提交。

git reset HEAD~5

  使用--soft指令，可以撤销对本地仓库的提交将版本回退到历史版本，但不影响工作目录和暂存区未完成的修改。也即只回退版本库，但不影响暂存区和工作区。

git reset --soft HEAD^

  使用--mixed指令，回退版本库和暂存区，实际上--mixed可以被省略，也就是默认情况下的git reset指令。

git reset --mixed HEAD^

  使用--hard指令，回退版本库、暂存区、工作区。用这个指令要小心，因为工作区的修改是没有版本控制的，一旦工作区的修改没了是无法恢复的。

git reset --hard HEAD^

1.2.2 git revert

  git revert特殊之处在于其回退版本后中间“跨过”的版本也都会保留，并且HEAD也会在原来基础上增加，也即不影响之前的提交内容。指令用法与git reset是类似的。

git revert HEAD^^

git revert HEAD~5

  回退版本时可以直接指定版本的Hash编号或标签。

git revert <commit>