关于Git

——From 《Version Control with Git》

很久没有更新了,很多事情还是要坚持吧,最近虽然表面上学了很多东西,但是这些框架里面有多少会留下,应该想清楚

 

当多个人进行并行开发时,Git的作用就显现出来了。不得不说,Git很强大,但也有些些许复杂。

首先是Git的组织方式,根据存储状态的不同分为暂存区(stage)和对象库(object store),这么说也就表明,其实暂存区和索引(index)是一样的,本质都是一种树对象,至于工作区就是工作目录。对象库是Git版本库实现的核心,而前面提到的树对象则是Git放在对象库里的4中对象之一。Git放在对象库里的对象只有这4种:

  • 块(blob)负责最底层的存储,只有数据,没有任何描述数据的信息
  • 目录树(tree)负责组织最底层的数据,包含描述数据的信息
  • 提交(commit)负责记录每一个点的状态
  • 标签(tag)对特定状态的引用

所以实际上我们需要管理的就是提交,在只有一个分支的情况下应该不会有任何需要纠结的地方。但是当涉及到远端或者多个分支的时候就会出现问题。

接下来就涉及到了Git的另一个重要的概念,分支(branch),当然有分支就会有合并(merge)。当涉及到远端时,虽然表面上可以装作是只有一个分支,但是一个分支不会出现同时将一个文件改成两种样子的情况,这种情况下,Git自然会当成两个分支来处理,抛开这种方式是否优雅,先来说说这种情况出现了最佳的解决方案是什么。这个问题被称为非快进推送问题,当涉及到分布式开发的时候,虽然本地和远端都是master分支,但是其实是两个分支,一个是origin/master,另一个是本地的master,当两者出现不一致时肯定就无法简单的进行pull和push。对于这种冲突,一种解决方式就是常见的merge,pull本身也是fetch后进行merge,但是假如已经在pull之前进行了commit,这个时候进行merge就会形成环(两个分支并为一个),如果经常发生这种情况就会导致整个开发路径变得凌乱,所以这种时候用另一种方式——变基(rebase)也许更适合。rebase会将岔开的分支作为一个个提交接到最新的HEAD上,但是存在硬性冲突时,必须先决定是留下ours或者theirs,这个时候可能会变麻烦。对于这种硬性冲突,最好的办法就是先接受一方代码,在其基础上进行修改后进行新的提交。

目前对于Git中的最佳实践还是缺少了解,不过一定会有一个更加优雅的方式。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注