Git笔记

想到哪写到哪

首先明确Git的三个区，工作区 -> 暂存区 -> 版本区

这个博客写的很好 https://www.cnblogs.com/songxiaohua/p/9626849.html

一、git reset的用法

1. 一种是已经add，还没有commit，想要撤回add操作，使文件从暂存区移动到工作区，使用如下命令

git reset HEAD 文件名

2. 另一种是已经commit，想要回退到其他版本，有三种操作

<1> --hard （危险命令，慎用）

将三个区（工作区、暂存区和版本区）和想要回退的版本一模一样，即清空工作区和暂存区

git reset --hard HEAD^ (此处可以写多个^，且必须和HEAD挨着，也可以在^后面加上数字，表示回退次数如^2，Mac可能要用~）
or
git reset --hard 版本号

<2> --soft

不动工作区和暂存区的东西，仅使版本区的文件回退至对应版本。若你暂存区或者工作区修改的文件和回退的文件产生冲突，则暂存区或工作区的文件不会受到影响，仍然存在于工作区或暂存区

git reset --soft HEAD^
or
git reset --soft 版本号

<3> --mixed（默认就是这个）

不动工作区的东西，但是会清空暂存区的东西。若你暂存区或者工作区修改的文件和回退的文件产生冲突，则将暂存区的冲突文件放至工作区，总之最后你的暂存区一定是干净的！

git reset --mixed HEAD^
or
git reset --mixed 版本号

二、checkout的使用

1. 使工作区的文件和暂存区 / 版本区的对应文件保持一致，若暂存区和版本区均有该文件，则优先和暂存区的文件保持一致

git checkout -- 文件名
or
git checkout -- . （全部工作区的文件）

2. 切换分支

git checkout 分支名
git checkout -b 新的分支名 （创建自己的分支，并切换到该分支）

三、rebase

谈谈我的理解，我在dev1分支执行如下命令

git rebase dev2

会发生什么事呢？

首先，这是在本地，和远程没有关系。dev1和dev2这两个分支一定是会形成一个“Y”字形的，即一个二叉树，首先Git会找到两个分支的最近公共祖先，即那个交汇处，接着，为了方便叙述，我令那个交汇处为节点N，沿着节点N顺着dev1的那条分支，我叫它s1，沿着节点N顺着dev2的那条分支，我叫它s2。然后，s1上肯定有很多节点，按节点顺序一个一个对其进行考察，分为下面三种情况

<1> 这个节点在s2分支中不存在

则直接添加到s2的末尾

<2> 这个节点在s2分支中存在，且内容无变化

不进行任何操作，即跳过这个节点，继续顺着s1这条路线考察下一个节点，直至最后一个

<3> 这个节点在s2分支中存在，且内容有变化

产生冲突，rebase失败，怎么办？不要慌，此时又有以下三种选择

① 这个节点我不考察了！我跳过去！即你抛弃了s1的那个冲突文件，还是选择s2里面的文件内容，下面的命令是危险命令，因为如果你skip了这个节点，那么就意味着你选择遵从s2而不是s1，那么你在s1中的这个节点将被丢弃掉！慎用啊！

git rebase --skip (危险命令，慎用！)

② 呜呜呜，我不想rebase了，我要再考虑考虑再rebase，我要回到原始状态！

git rebase --abort

③ 我就是要解决冲突！我自己手动改！（其实这里，你又有三种选择，一个是s1往s2对齐，一个是s2往s1对齐，一个是都不对齐，我自己把s1和s2的都改了，并且都改成一样的！）

嗯，等你改完以后，你想继续rebase，执行下面的命令

git add 你修改的文件
git rebase --continue

这样就rebase结束啦！