进入点融之前,笔者的版本控制一直用的是SVN。在加入点融后,接触到了GIT,也使笔者有机会学习到更为广泛应用的GIT版本控制。
通过同事帮助和自主学习,以及在一些网络上学习到Git相关知识的基础之上,笔者将从大的方面来阐述一下GIT与SVN的区别。
GIT跟SVN一样有自己的集中式版本库或服务器,但是GIT更倾向于被使用于分布式模式,也就是每个开发人员从中心版本库/服务器上checkout代码后会在自己的机器上克隆一个自己的版本库。举个例子,如果你被困在一个不能连接网络的地方时,如飞机上,地下室,电梯里等,你仍然能够提交文件,查看历史版本记录,创建项目分支等等。
所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。如果你把.git目录的体积大小跟.svn比较,你会发现它们差距很大。因为.git目录是处于你的机器上的一个克隆版的版本库,它拥有中心版本库上所有的东西,例如标签,分支,版本记录等。
分支在SVN中一点不特别,就是版本库中的另外的一个目录。然而,处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支,你能简单而快捷的合并这些文件。
言归正传,接下来,本文将主要介绍的rebase命令的操作。
在实际项目开发过程当中,开发人员都会从远程主分支克隆代码到本地,然后在此基础之上,进行自己的功能开发。在本地开发的同时,远程主分支也会不断有其他同事开发的功能被push上去。在本地开发的代码,可以通过fetch,然后在merge提交到本地或者直接pull到本地来做作为本地同步远程代码的目的,当然在此笔者主要想讲述的是如何通过统一远程和本地的代码的log,从而神不知鬼不觉的去同步代码。
我们来具体演示一下rebase的用法。
首先克隆远程主分支到本地主分支(master),然后创建自己的分支(test),具体demo如下图所示:
此时test分支的版本如下:
主分支master,在其他同事的不断push后,现在的版本如下:
如上图所示,当前主分支有新的代码提交,本地分支开发人员每天也会有新的代码提交。但是往往一个功能模块的开发是需要好几天才能完成的,故一个功能点往往会产生多个log,关于如何合并多个提交log,后面会讲述(详见步骤8)。接下来,在本地开发人员进行功能开发结束后,如下图所示:
如上图所示,可以看到开发人员在本地分支提交了3次代码,完成了功能开发,接下来就要进行rebase操作,如下图所示:
在rebase过程当中可能需要处理一些冲突,具体操作如下图所示:
如上图所示,rebase结束,具体结果如下所示:
接下来主要看一下,如果合并分支多次提交log,运行命令如下:
git
rebase -i 9b67ef73b1225777153aad76de0dee444fa9d892
会跳出vim编辑模式,修改除第一个外的后面几个pick为s或者squash,将log改为:test合并之前提交的1,2,3;
如下所示:
到此合并结束,具体结果如下:
至此,这个rebase基本功能用法就介绍完毕了。在操作过程当中,可能要解决一些冲突,merge一些代码,提交之后,才可以继续操作。一般情况下,敲入命令: git status ,查看当前版本下的提示情况之后,再进行相应操作,就可以了。
希望笔者对此命令的一些心得体会可以帮助更多的开发人员理解GIT,可以更好的上手应用GIT,有更多关于GIT的心得体会,欢迎与笔者探讨。