Git 命令 checkout、reset、revert、reflog 使用介绍_git checkout reset

目录

checkout 项目回滚

reset 项目重置

重置暂存文件

重置到指定版本

重置后的强制推送

git reflog 反重置

revert 项目恢复

rebase VS merge 

分支开发工作流

---

checkout 项目回滚

1、开发中会出现对一些文件内容修改后，觉得并不满意、或者不小心改错了文件等情况，这个时候除了用 Ctrl + Z 撤销文件，还可以使用 "git checkout -- fileName" 命令轻松的将内容回滚到之前的状态。

2、注意：使用了 "git add" 添加到了暂存区的文件无法再回滚 (checkout)。

reset 项目重置

1、git reset 的作用是修改 HEAD 的位置，将 HEAD 指向的位置改变为之前存在的某个版本(commit)。如果想恢复到之前某个提交 (commit) 的版本，且那个版本之后提交的版本不需要了，则可以用这种方法。

2、"git reset" 命令把当前分支指向另一个位置，并且相应的变动工作区和暂存区。

3、回滚(checkout)针对小事件，少量的文件是很方便的，但如果开发中大面积的文件内容被修改后，发现功能出现了严重的问题，或者需求发生了改变等等，此时用回滚已经显得力不从心了，此时可直接重置。

4、对于修改的内容如果做了"git add"操作，将文件放入到了暂存区，那么"git checkout -- fileName"也无能为力，此时也需要重置。

重置暂存文件

 1、对于新建的文件、目录，只是 git add 添加到暂存区的文件，可以直接 git reset 文件/目录 重置暂存，让文件重新处于未被跟踪状态。省略文件/目录时，重置所有。

2、在上个版本提交后修改了文件，git add 添加到暂存区后，此时 git reset --hard 重置到上个版本，在重置文件状态的同时，也会重置文件内容。

重置到指定版本

1、如下所示，可以使用 git log 命令查询所有提交的(commit)版本，然后可以选择自己需要版本进行重置回去。

2、git log 可以查看到所有 commit （提交）过的版本信息（时间、版本号、作者等），其中 HEAD -> master 表示当前的版本号。

3、git reset -hard <commit> 以后，可以看到直接重置到目标版本处，后面的版本已经不存在了.

4、除了在本地使用 git log 命令查看所有版本号以外，还可以在 github 仓库主页的 commit 菜单下看到 push 来的 commit 的版本号。

重置后的强制推送

5、git push 推送到远程仓库的时候需要注意，如果回退的版本之前还没有 push 到远程仓库，则重置之后可以直接 push，否则如果回退的版本已经 push 到远程仓库，则此时需要使用 git push -f 进行强行推送，否则 git push 会报错。

$ git push
To https://github.com/wangmaoxiong/h2Smil.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/wangmaoxiong/h2Smil.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Administrator@SC-201706302213 MINGW64 /f/gitWorkSpace/h2Smil (master)
$ git push -f
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/wangmaoxiong/h2Smil.git
 + 11ebdbe...f207132 master -> master (forced update)
Administrator@SC-201706302213 MINGW64 /f/gitWorkSpace/h2Smil (master)

git reflog 反重置

1、提交历史比如 a -> b -> c -d，因为某些原因使用 git reset 回滚到了版本 b，做了一些修改（或者没做修改）后发现不应该重置，现在又想要回到之前的 d 版本。

2、理论上 git reset 只要知道目标版本号，则可以重置到任意时刻。此时 git log 只能看到 a 与 b 的版本号信息，c、d 看不到了，应该使用 git reflog 进行查看。

3、git log 查看的日志限于当前存在的提交历史，git reflog 可以查看本地所做的任意提交历史，包括已经被删除的。

revert 项目恢复

1、git revert 是通过创建一个新的版本，且内容与回退的目标版本一致，但是 HEAD 指针是指向这个新生成的版本，而不是目标版本。

可以参考 Git恢复之前版本的两种方法reset、revert（图文详解）_游笑天涯的博客-CSDN博客_git reset revert

rebase VS merge 

1、假如有如下两个分支 test和master。

      D---E test
     /
A---B---C---F master

2、在 master 执行 git merge test 后会得到如下结果：

      D--------E
     /          \
A---B---C---F----G   test, master

3、在 master 执行 git rebase test后得到如下结果：

A---B---D---E---C'---F'   test, master

4、可以看到 merge 操作会生成一个新的节点，之前的提交分开显示，rebase 操作不会生成新的节点，是将两个分支融合成一个线性的提交。

5、如果想要一个干净的没有 merge commit 的线性历史树，那么应该选择git rebase；如果想保留完整的历史记录，并且想要避免重写 commit history 的风险，则应该选择使用 git merge(常用方式)

分支开发工作流

1）长期分支

1、因为 git merge 使用简单的三方合并，所以就算在一段较长的时间内，反复把一个分支合并入另一个分支，也不是什么难事。 整个项目开发周期的不同阶段，可以同时拥有多个开放的分支，可以定期地把某些特性分支合并入其他分支中。

2、比如只在 master 分支上保留完全稳定的代码（可能仅仅是已经发布或即将发布的代码），他们还有一些名为 develop 或者 next 的平行分支，被用来做后续开发或者测试稳定性，这些分支不必保持绝对稳定，但是一旦达到稳定状态，它们就可以被合并入 master 分支了。

3、稳定分支的指针总是在提交历史中落后一大截，而前沿分支的指针往往比较靠前：

4、通常把他们想象成流水线（work silos），那些经过测试考验的提交会被遴选到更加稳定的流水线上去。

5、可以用这种方法维护不同层次的稳定性，这么做的目的是使你的分支具有不同级别的稳定性，当它们具有一定程度的稳定性后，再把它们合并入具有更高级别稳定性的分支中。 当然使用多个长期分支的方法并非必要，但是这么做通常很有帮助，尤其是当你在一个非常庞大或者复杂的项目中工作时。

2）特性分支

1、特性分支对任何规模的项目都适用，特性分支是一种短期分支，它被用来实现单一特性或其相关工作。因为在 Git 中一天之内多次创建、使用、合并、删除分支都很常见。

2、工作被分散到不同的流水线中，在不同的流水线中每个分支都仅与其目标特性相关，因此在做代码审查之类的工作的时候就能更加容易地看出你做了哪些改动。可以把做出的改动在特性分支中保留几分钟、几天甚至几个月，等它们成熟之后再合并，而不用在乎它们建立的顺序或工作进度。

3、考虑这样一个例子，你在 master 分支上工作到 C1，这时为了解决一个问题而新建 iss91 分支，在 iss91分支上工作到 C4，然而对于那个问题你又有了新的想法，于是你再新建一个 iss91v2 分支试图用另一种方法解决那个问题，接着你回到 master 分支工作了一会儿，你又冒出了一个不太确定的想法，你便在 C10的时候新建一个 dumbidea 分支，并在上面做些实验。 于是你的提交历史看起来像下面这个样子：

4、现在假设：你决定使用第二个方案 iss91v2 来解决那个问题，另外你将 dumbidea 分支拿给你的同事看过之后，结果发现这是个惊人之举。 这时你可以抛弃 iss91 分支（即丢弃 C5 和 C6 提交），然后把另外两个分支合并入主干分支。于是提交历史看起来像下面这个样子：