全部学习汇总： GitHub - GreyZhang/g_unix: some basic learning about unix operating system.

 

         目前没有很好的笔记分类放置这一份学习笔记，因为我的工具箱分类并不适合它。我之前的工具箱笔记主要还是简洁扼要来列出工具使用的参考，而这个其实是版本管理的一个学习。那么，既然我是因为看了OS的教程参考资料找到的这部分信息，暂且还是归类到这里面。阅读的这一份资料非常简短，但是的确是能够很好阐明版本管理的一些行为意图。

         在git的版本管理中，每一个提交都可以作为一个blob对象，而这样的对象不能够是一个孤立的对象。至少，他会跟某些节点产生一些联系。

         如果一个节点没有父提交，那么意味着这个节点是初始提交。有意思的是初始提交其实是可以有多个的，这通常意味着多个项目的合并。

1. 参考引用、head、branch等这样的额概念，其实只是一个标记不会存入到版本之中。

2. 通过提交动作可以整个管理树中增加节点。

3. HEAD是一个比较特殊的引用，因为它指向了另一个引用。

4. 远程引用与本地引用的差别在于指向的命名空间不同，远程引用的内容由远程机器控制，git只是引用它并且可以获得它的相关更新。

1. 什么是tag呢？tag既是一个图上的节点，又包含了标签信息。由此可以知道，tag本身其实是意味着有一次提交的。

2. Git库本质上是一系列的节点与标签的组合。

1. 图1表达的概念：当前的repo有本地以及远程引用，并且远程引用已经有了新的更新。然而，当前的repo使用的还是旧的远程版本。

2. 图2在图1的基础上，进行了本地与远程的合并。由于此时本地的库没有任何提交更新，因此这样的合并只是移动一下master标签即可。

3. 图3则复杂了一点，不仅有远程更新而且有了本地的提交更新。如此，版本需要进行合并处理。

1. 第一个图中，创建了一个新的节点e，其实只是为了合并本地以及远程分支。这里的节点e比较特殊，因为它有两个父提交。

2. 理解了第一个图，第二个图的理解就比较容易了。因为这只是相同的情况出现了多次的处理过程。

         这一页介绍了rebase的概念。通过描述可以知道，rebase其实是放弃了一部分之前的信息，这些信息可能是改变远程引用的指向，也可能只是放弃一些本地的信息。对于上面的图1来说，表达的概念其实是：我原本的repo使用了远程节点b，但是现在的c兴许更好，以后的开发使用大家都不要用b了，要去使用c。

         而这一个例子则更能够表达通用场景，结合上一页的原始图信息。我现在的repo引用了远程库的c，在此基础上有了本地的提交d2，又有了提交h。同时，本地库中基于远程引用的g也有了一个新的提交d3。之后，我觉得d3能够表达我现在对于开发最好的期待，因此我又增加了一次更新h2。这时候，我发现d2和h其实没什么用途了。我也不想其他人在此基础上继续开发，因此想要放弃这部分信息。于是，通过rebase可以直接把版本迁移到d3开始的主线上。结果，rebase的命令比较聪明，它发现我在d3基础上已经做了更新到了h2，因此它会把标签移动到h2作为master。

         原始阅读的时候，有些地方理解的并不是很准确，标注也不是很对。但是整理的过程中进行了一定的纠正，这也是整理笔记的意义所在吧！