Git之rebase操作分享

进入点融之前，笔者的版本控制一直用的是SVN。在加入点融后，接触到了GIT，也使笔者有机会学习到更为广泛应用的GIT版本控制。

通过同事帮助和自主学习，以及在一些网络上学习到Git相关知识的基础之上，笔者将从大的方面来阐述一下GIT与SVN的区别。

1、控制版本

最核心的区别，GIT是分布式控制版本，而SVN不是。

GIT跟SVN一样有自己的集中式版本库或服务器，但是GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上checkout代码后会在自己的机器上克隆一个自己的版本库。举个例子，如果你被困在一个不能连接网络的地方时，如飞机上，地下室，电梯里等，你仍然能够提交文件，查看历史版本记录，创建项目分支等等。

2、存储方式

GIT把内容按元数据方式存储，而SVN是按文件。

所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn，.cvs等的文件夹里。如果你把.git目录的体积大小跟.svn比较，你会发现它们差距很大。因为.git目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。

3、分支

GIT分支和SVN的分支不同。

分支在SVN中一点不特别，就是版本库中的另外的一个目录。然而，处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支，你能简单而快捷的合并这些文件。

4、rebase命令的操作

言归正传，接下来，本文将主要介绍的rebase命令的操作。

在实际项目开发过程当中，开发人员都会从远程主分支克隆代码到本地，然后在此基础之上，进行自己的功能开发。在本地开发的同时，远程主分支也会不断有其他同事开发的功能被push上去。在本地开发的代码，可以通过fetch，然后在merge提交到本地或者直接pull到本地来做作为本地同步远程代码的目的，当然在此笔者主要想讲述的是如何通过统一远程和本地的代码的log，从而神不知鬼不觉的去同步代码。

我们来具体演示一下rebase的用法。

首先克隆远程主分支到本地主分支(master)，然后创建自己的分支(test)，具体demo如下图所示：

此时test分支的版本如下：

主分支master，在其他同事的不断push后，现在的版本如下：

如上图所示，当前主分支有新的代码提交，本地分支开发人员每天也会有新的代码提交。但是往往一个功能模块的开发是需要好几天才能完成的，故一个功能点往往会产生多个log，关于如何合并多个提交log，后面会讲述(详见步骤８)。接下来，在本地开发人员进行功能开发结束后，如下图所示：

如上图所示，可以看到开发人员在本地分支提交了３次代码，完成了功能开发，接下来就要进行rebase操作，如下图所示：

在rebase过程当中可能需要处理一些冲突，具体操作如下图所示：

如上图所示，rebase结束，具体结果如下所示：

接下来主要看一下，如果合并分支多次提交log，运行命令如下：

git

rebase -i 9b67ef73b1225777153aad76de0dee444fa9d892

会跳出vim编辑模式，修改除第一个外的后面几个pick为s或者squash，将log改为：test合并之前提交的1,2,3；

如下所示：

到此合并结束，具体结果如下：

至此，这个rebase基本功能用法就介绍完毕了。在操作过程当中，可能要解决一些冲突，merge一些代码，提交之后，才可以继续操作。一般情况下，敲入命令:git status，查看当前版本下的提示情况之后，再进行相应操作，就可以了。

希望笔者对此命令的一些心得体会可以帮助更多的开发人员理解GIT，可以更好的上手应用GIT，有更多关于GIT的心得体会，欢迎与笔者探讨。

本文作者：张金周（点融黑帮），现任点融FinTech团队后端开发工程师，江西理工大学计算机专业。工作三年，两年外企经验，平时研究后端框架，喜欢学习前端技术以及新技术。业余时间喜欢打羽毛球，看电影。