Git窗口使用、历史不可修改但具有分流 及 本地仓库合并冲突 （本地操作）

一、Git窗口使用

基本本地仓库操作：

$ git init              //初始化本地仓库
$ vim 1.txt             //新建1.txt，也可以手动在文件夹中建立
//接下来在1.txt中进行编辑，后按Esc切换到下面指令行，输入 :wq 保存文件并退出编辑
$ git add 1.txt        //添加到暂存区，也可以写为 add .  代表着选中所有文件
$ git commit -m "first write"    //上传至本地仓库，后面可以跟文件名也可以不跟

本地仓库中日志查看及版本回退：

$ git log        //查看详细日志
$ git reflog     //查看简略日志
$ git reset --hard 710ebb806a098ab2677b8d02858fd0602d3833c2  
                 //版本回退后面跟的是Hash值，即日志中那一长串串
                 //hard回退后会重置暂存区，即也会更改文件夹中文件的可视状况。
$ git reset --soft 710ebb806a098ab2677b8d02858fd0602d3833c2
                 //soft回退后不会更改文件的状况，只是回退到那次commit后的状态

本地仓库中创建新分支与切换分支：

$ git branch fenzhi         //生成新分支 fenzhi
$ git checkout fenzhi       //切换进入fenzhi中
//必须有历史相关文件/基地文件才能创建新分支，也就是master至少有一次commit后才可以创建新分支
//分支创建后进行修改，后进行合并，合并需要注意分支合并冲突（该情况在下文解释）
$ git merge master         //*此时在要合并的fenzhi分支中，该操作将master合并给fenzhi

二、历史不可修改但具有分流

首先，我们新建一个文件夹，并进行以下操作：

 此时，我们用hard回退到第一次的状态，即五个空白txt的状态，并对1.txt进行重新书写并进行commit：

 此时接着回到现在（回到现在的版本）：

发现并没有记录回退后对1.txt的修改，说明历史不可修改。 

但回退到企图修改历史版本，并写入其Hash值可跳转，可见修改仍存在：

 因此，我们可以简单理解为：

三、分支合并冲突：

以一个例子来说明：

首先，我们在git中创建一个Git-demo文件，在该文件中完成仓库初始化，并新建一个1.txt文件，进行commit。此时该1.txt文件内容为空。

 接着，我们创建新的分支并切换到新的分支中：

 然后，我们在fenzhi这个新分支中对该文件进行修改，并可以看到它的日志记录：

 然后，此时我们切换到master分支并对master分支中的1.txt进行修改：

 此时，我们已经做了两个动作：几乎同时在master分支中与fenzhi分支中对1.txt这个历史相关文件进行了修改，我们来进行分支合并则会产生冲突：

需要解决该分支冲突，则是需要修改1.txt的内容，意义在于该解决方式给了编译者操作空间，由编译者自行选用哪条编码。解决分支冲突后进行add和commit，可在日志中查看到。

 至此，合并冲突解决。

---

要知道：分支合并冲突的根本原因在于日志中历史快照同名文件操作的日志记录的相异性。简单来说有以下三种情况可以导致分支合并冲突：

1、两个分支都对历史相关的同名文件做了处理并进行了commit。

2、对历史不相关的同名文件都进行了处理，然后commit。

---