还记得在食堂排队吗，假设好多同学喜欢看到认识的同学就喜欢插队，只是他的插队不是直接插入，而站在队外面，然后来了新人看到了，又插到他后面，很快我们就看到食堂窗口那里变成了一颗树了。

好的，我们先来一个人排队：

查看分支：

我们开始插队，创建一个新分支roma:

在新分支上修改文件，然后提交一下，就相当于又插队了一个人：

好的，现在roma分支上我们已经完成了插队，而master分支还只有一个人"init"，现在查看一下roma分支上有几个人了：

下面是简化SAH1输出的命令格式，一般情况下我们都不需要输出SAH1的值，可以用格式化输出的方式：

因为分支roma的修改都是在init的基础上添加的，所以合并的话不存在任何冲突，就好像是从master生长出来的一样：

好了roma的工作都被合并到主线上了，如果确认没有问题，就可以把roma分支销毁了：

??

解决冲突

刚才是没有冲突的情况因为master上没有动作，现在我们在master上和分支上都动一动：

创建新分支roma，并且做一些修改：

然后再切换到master分支上动一动：

好了现在我们正好在master下，然后合并roma到master上：

这里直接把后两行删掉或者改掉：只要把冲突的行改成你想改的任何形式都可以：

经发现这么改不行，可以！是我的操作步骤错了：改完之后还用暂存并提价冲突解决修改：

注意要把 -a 放到 git commit -m "conflict solved" -a 的后面，而不能和-m连写

其实这里的-a表示的git add .标记冲突修改完成。

rebase

"命令git-rebase也可以合并一个分支的开发成果到另外一个分支。不同的是，被rebase的分支的历史会被整体搬移到当前分支上。"这句话该怎么理解呢？整体搬移有什么好处呢？

我想到一个好处：就是完整地保留分支的修订历史，而合并则忽略了修订历史，所以用git rebase 可能是更好的选择比git merge.

先构造一个有多分支的仓库作为实验环境：

我们切换回master分支，然后添加一个"r2"commit

再查看roma分支的修订历史：

虽然，roma分支上rI是从r1生成的，而在master分支上，r1上又生成了r2，现在我们要让rI搬到r1，虽然有些不合理啊：但是这里搬过去的rI其实是roma的rI对master的r2的一个修订：

好的现在我们修改冲突，把修改后的状体作为新的"rI"嫁接到master的"r2"上去：

好吧，这里出现问题，我原先预期是把rI嫁接到r2上的，现在乱了。原因可能出在

命令上：应该切换到roma分支上，然后运用git rebase master而不是git rebase roma，这个的意思是把当前分支的全部修订搬移到指定分支master上，两个分支的历史合并为一条单线，最后roma的修订历史会变成这样：

然后还有一步操作：

git checkout master

git merge roma

这才得到：

??

??

撤销 git rebase

这个其实类似撤销提交，也是git reset命令，准确地将是和恢复撤销类似，也用到了双层空间查看命令git reflog

git reset --hard HEAD@{4} 这样一来就回退到了这个状态

--hard的作用是告诉git-reset命令不仅修改仓库的当前修订位置，也会同时使用此修订的文件来覆盖工作区和暂存区的文件。

??

??

??

-----------------------------------------------------------------

分层：是为了抽取共性，便于管理，防止混乱

目录：是为了区分

分类：基于臭味相投

设计模式：到底有什么用

-----------------------------------------------------------------

如果虚拟机无法共享文件夹可以用优盘

-----------------------------------------------------------------

看到书后面还有那么多突然急躁了，感觉看书还是实验一遍自己截个图，一来避免了急躁，二来加深了印象。

《Git小书》笔记：6 分支