永久删除文件后找回

新建一个2.txt，并且提交到暂存区、本地库：

然后使用rm 2.txt删除2.txt

把删除2.txt的操作提交到暂存区、本地库：

现在2.txt已经被永久删除了。
但是版本提交的历史记录是一直存在的，每一个版本都有，也就是说rm 2.txt之前的版本也存在，所以2.txt是能找回来的：

可以看到2.txt被找回来了，后悔药服用成功。

但是.git这个文件夹你不能删掉，删掉就真没了。


添加到暂存区的删除文件找回

新建一个3.txt，提交到暂存区和本地库：

然后删掉3.txt，提交到暂存区：

这时可以使用git reset --hard HEAD来找回3.txt文件：

原理是同步工作区为本地库的指针HEAD指向的版本，刷新暂存区，而本地库的HEAD指向的是new 3.txt这个版本，所以文件找回来了。


删除找回总结

前提：删除前，文件存在的版本提交到了本地库。
操作：git reset --hard <指针位置>

  • 删除操作已经提交到本地库：指针位置指向历史记录
  • 删除操作尚未提交到本地库：指针位置使用HEAD

比较文件

修改一下1.txt的文件内容：

然后使用git diff 1.txt把工作区文件和暂存区比较，查看文件的变动：

-红字表示删掉的内容，+绿字表示新增的内容，以行为单位。

如果执行git add 1.txt加到暂存区，就不会用什么显示，因为工作区和暂存区一致，没有变动：

我们还可以把工作区文件和某一历史版本文件进行比较，如

git diff b25b444 1.txt

不带文件名，如git diff head，可以同时比较多个文件：

总结：

  • git diff <文件名>
    将工作区中的文件和暂存区进行比较

  • git diff <本地库中历史版本> <文件名>
    将工作区中的文件和本地库历史记录比较

  • 不带文件名比较多个文件


分支概述

分支：在版本控制过程中，使用多条线同时推进多个任务。

master表示主干
feature_blue表示开发一套蓝色的主题的分支
feature_game表示开发一个小游戏的分支
这些分支彼此独立，如果不合并的话就互不影响。所以如果其中某一分支开发失败，删除分支即可，对整个项目没有影响，方便试错。对项目推进的效率也很有帮助，多个分支可以齐头并进，不必等项目主体开发完再开始。
分支开发完成后没有问题就可以合并到master主干，进行产品升级。
主干也可能出现bug，这时可以使用专门用来修复bug的hot_fix分支来修复，意思是热修复，因为服务器是不停运行的，在运行过程中修复就是热修复。相应地，停掉服务器再修复就是冷修复。

从上面的过程我们可以总结出分支的好处：

  • 同时并行推进多个功能开发，提高开发效率。
  • 各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响。失败的分支删除重新开始即可。

插曲小tip：Ctrl + L 可以实现清屏的效果。（实际上不是清屏，只是翻页了而已）


分支操作

  • 查看分支：git brach -v
  • 创建分支：git branch <分支名>
  • 切换分支：git checkout <分支名>

我们新建了一个hot_fix分支，并切换到了这个分支。
在这个分支上进行操作并提交到本地库当然也会进行版本更新：

这时hot_fix分支的版本就比master的版本更领先，假设这时说明hot_fix的功能已经实现了，需要合并到master主干，就需要进行分支合并。
进行分支合并时必须在接受合并的分支（master）上，然后再执行合并指令，也就是：

  1. 第一步：git checkout <接受合并分支名>
  2. 第二步：git merge <有新内容分支名>


分支合并时冲突的解决

当在两个分支分别修改时，恰好修改的是同一文件的同一位置，分支合并时就会出现冲突。
现在我们在master分支和hot_fix分支都修改1.txt文件中的同一行：
master中：

hot_fix中：
（有句命令手残敲错了一次）

这时再合并（往hot_fix上合并master也是可以的）就会出现：

意思是自动合并失败，需要我们手动合并，MERGING就表示正在合并。
这时用vim 1.txt打开1.txt查看，会出现这样的内容：

增加了一些特殊的标记。
以=======为分界，HEAD指向的，即333333 edit bt bot_fix（应该是by，敲错了）表示当前分支内容，333333 edit bt master表示master分支内容。

处理方式很容易理解，在此vim编辑器中删掉不需要的内容、留下需要的，就行了。
现在我什么都不修改，假设已经决定好了，直接退出，然后git add 1.txt、git commit（注意git commit后不要带文件名）。

冲突解决，合并完成。然后使用cat 1.txt看一下：

可以看到其内容就是刚才MERGING过程中编辑的内容