还记得在食堂排队吗，假设好多同学喜欢看到认识的同学就喜欢插队，只是他的插队不是直接插入，而站在队外面，然后来了新人看到了，又插到他后面，很快我们就看到食堂窗口那里变成了一颗树了。
好的，我们先来一个人排队：
查看分支：
我们开始插队，创建一个新分支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 [email protected]{4} 这样一来就回退到了这个状态
--hard的作用是告诉git-reset命令不仅修改仓库的当前修订位置，也会同时使用此修订的文件来覆盖工作区和暂存区的文件。
?
?
?
?
?
?
-----------------------------------------------------------------
分层：是为了抽取共性，便于管理，防止混乱
目录：是为了区分
分类：基于臭味相投
设计模式：到底有什么用
-----------------------------------------------------------------
如果虚拟机无法共享文件夹可以用优盘
-----------------------------------------------------------------
看到书后面还有那么多突然急躁了，感觉看书还是实验一遍自己截个图，一来避免了急躁，二来加深了印象。