Git总结

书籍参考:猴子都能懂的Git入门🐵
软件推荐:GitHub(功能简单)、TortoiseGit(😘图形版的Git命令行,可谓将命令行的功能全部都以图形界面的方式展现了出来,强)

1、Git是一个分布式版本管理系统,是为了更好地管理Linux内核开发而创立的。Git可以在任何时间点,把文档的状态作为更新记录(修改提交记录)保存起来。因此可以把编辑过的文档复原到以前的状态,也可以显示编辑前后的内容差异。

2、工作树、索引、数据库之间的关系。
工作树(又叫工作区):在一个指定目录下实际进行文件操作的地方。
索引(又叫缓存区):可以理解为工作树更改前的镜像,并且其中还保存着哪些需要被跟踪的文件名(即通过add添加的文件名)。(当提交时,git首先会根据那些被指定跟踪的文件,在工作树与索引镜像之间通过diff进行差异对比,然后将所有的这些差异内容打包提交到数据库,并更新对应分支链表节点的信息及HEAD。 所以,凭借中间的索引,可以避免工作树中不必要的文件提交,还可以将文件修改内容的一部分加入索引区域并提交。)
数据库(又叫版本库):集合所有提交(修改记录、被打包的差异内容)的地方。
image

3、Git初始化时,会自动将目录树中的内容和索引中的内容进行全部同步,之后只有当提交的时候,才会在索引中针对这些提交的内容再次进行部分同步。

4、Git中的四种远端操作。

  • fetch(获取):只下载远端数据库的最新提交记录(不是全部提交),不进行其它的操作。 (取得的提交会导入到没有名字的分支,这个分支可以从名为FETCH_HEAD的退出。)
  • pull(拉取):下载远端数据库最新的提交记录并与本地数据库进行合并。(取得的提交会导入到名为origin/master的分支)
  • push(推送):推送本地数据库最新的提交记录到远端数据库要进行 fast-forward 合并。( 如果合并发生冲突,push会被远端数据库拒绝。)
  • clone(克隆): 完整复制远端数据库、索引、目录树的内容。(克隆后的本地数据库的变更履历也会被复制,所以可以像原始的数据库一样进行查看记录或其他操作。)
    image

5、Pull和Push的区别。
本地各分支之间的合并通常都是先切换到主分支/主题分支,然后合并指定的分支到主分支/主题分支,主分支/主题分支的版本库信息增加。但是当我们需要和远端数据库进行合并或被合并时,我们并不能通过切换分支来切换到远端分支处。这时便通过不同的指令来实现这种效果,那就是pull和push。
pull表示将远端分支合并到本地分支,push则表示将本地分支合并到远端分支。但是似乎不支持本地主题分支合并到远端主分支或远端主题分支合并到本地主分支这种操作。

  • pull=fetch+merge(switch本地)
  • push=merge(switch远端)只支持快进的合并,即push前需要先pull,然后才能正常merge。

6、分支说明。
git的分支记录,使用了类似数据结构中双向的链表结构,每一个节点都将指向下一个分支提交的节点,每个节点都对应一个实际的提交数据的内容,这样的好处就是很灵活的在各个节点内容之间跳动,且无严重的冗余节点数据。
如果每一个分支都是通过复制主分支数据库(两者完全独立)的话,对于一个很大数据变动的项目来说,耗时且费力,而且容易出现纰漏。

7、两种合并操作Merge和Rebase的区别。

  • Merge合并:会将两个分支的内容混合在一块,然后新建一个合并提交,该提交中记录了分支中所有的记录。HEAD也会指向这个新建的合并提交节点上。(便于查询各分支中的记录,但是总体上来看各分支记录较为混杂不便于区分)
  • Rebase合并:会将一个分支的内容逐一附加到另一个分支上且不会新建合并提交,但是HEAD还是指向合并前所在的位置。(各分支记录一目了然)

例:Rebase重基实例
修改的分支issue3在rebase主分支master时,首先分支issue3的head会移动到分支起点处,对应的目录树也会卷回到分支的起点处,然后根据rebase master去卷动到master最新的提交节点处,然后再此节点处再次将issue3中的提交补充其后。此时若出现冲突,在改正冲突之后有rebase对应的提交命令去重新提交。
image

8、合并冲突。
各分支提交的节点就像是各集合中的元素一样,而分支的合并就像是集合的合并,各分支相同的部分(基于某个节点开始分支之前的部分)就像是集合相交的地方。
而节点对应的都是关于文件的修改操作内容,如果两个分支的所有节点所对应的文件并没有相同的部分,那么两分支的所有节点都可以不分先后的顺利合并而不影响最终的结果。而如果两分支的节点有相同的操作文件,或者一个分支的节点中有相同的操作文件,那么就会出现冲突或只能按顺序进行。冲突的部分程序不会进行修改解决,但是他会标记出来然后由人手动进行修改。
当我们对分支进行合并时,即便存在冲突git也会进行合并处理,然后指出冲突文件,当认为修改之后就又会产生一次冲突修改的提交。

9、关于Reset操作HEAD时的三种模式
使用reset可以遗弃不再使用的提交。执行遗弃时,需要根据影响的范围而指定不同的模式,可以指定是否复原索引或工作树的内容。(当HEAD在对应分支的节点进行向后向前移动时,Git会根据对应节点提交的记录进行撤销或重做的操作,此时不同的reset模式将决定索引和目录树中的内容是否会发生相应的变化。)
image

10、什么是HEAD。
HEAD相当于数据结构链表中的头指针,通过这个头指针来在各个提交记录的节点上进行移动,进而展现不一样的目录树以及其它的操作。通常HEAD默认指向master分支的最后一次更新。通过移动HEAD,就可以变更使用的分支。

HEAD的种类:HEAD、ORIG_HEAD、FETCH_HEAD。
image

11、贮藏区Stash。
stash是临时保存文件修改内容的区域。stash可以暂时保存工作树和索引里还没提交的修改内容以及新添加的文件,您可以事后再取出暂存的修改,应用到原先的分支或其他的分支上。
切换分支时,那些修改但未提交的记录会从原来的分支移动到新的切换分支上,这些修改内容会存在于切换后的目录树中,这样就可能会引起混乱。之所以出现这种情况,就是因为切换分支是通过移动HEAD进行的,故而会对现有目录树进行撤销和重做的操作。如果撤销/重做的操作文件中并未和现有目录树已修改的文件冲突,那么这个修改内容就会跟随切换分支,如果出现冲突,那么git会提醒先提交修改然后再切换分支,否则不进行切换。
image

12、命令行Git命令使用。

  • git rebase -i可以修改已提交的内容或注解。
  • 使用git reset --hard HEAD~~删除提交后,可以通过git reset --hard ORIG_HEAD来恢复。
posted @ 2022-03-28 18:28  扛枪的书生  阅读(124)  评论(0编辑  收藏  举报