7.库的回收和重命名
有的时候库迁移完成之后，老的库就不需要了，这个时候就需要我们去回收或重名了，接着上面的实例说明：
要求如下：
（1）我已经把linux_datagrand.git这个库里的文件迁移至linuxmi.git这个新库中了，那么我不想再使用git clone ssh://git@gitlab.linuxmicom:19234/linux/linuxmi.git 建立本地库；
（2）我想把linux_datagrand.git这个本地库更改为linuxmi.git
操作如下：
cd linux_datagrand
##先删除原先的origin
git remote remove origin
##查看当前远程仓库
git remote -v
test ssh://git@gitlab.linuxmicom:19234/linux/linuxmi.git (fetch)
test ssh://git@gitlab.linuxmicom:19234/linux/linuxmi.git (push)
##我们一般都习惯使用origin,所以更改一下test这个名称
命令格式：
git remote rename <old> <new>
git remote rename test origin
##再查看当前远程仓库
git remote -v
origin ssh://git@gitlab.linuxmicom:19234/linux/linuxmi.git (fetch)
origin ssh://git@gitlab.linuxmicom:19234/linux/linuxmi.git (push)
8.git pull 和 git pull --rebase
##说明：
Git 作为分布式版本控制系统，所有修改操作都是基于本地的，在团队协作过程中，假设你和你的同伴在本地中分别有各自的新提交，而你的同伴先于你 push 了代码到远程分支上，所以你必须先执行 git pull 来获取同伴的提交，然后才能 push 自己的提交到远程分支。而按照 Git 的默认策略，如果远程分支和本地分支之间的提交线图有分叉的话（即不是 fast-forwarded），Git 会执行一次 merge 操作，因此产生一次没意义的提交记录，从而造成了递交图像的混乱。
##解决：
其实在 pull 操作的时候，，使用 git pull --rebase 选项即可很好地解决上述问题。 加上 --rebase 参数的作用是，提交线图有分叉的话，Git 会 rebase 策略来代替默认的 merge 策略。 使用 rebase 策略有什么好处呢？借用一下 man git-merge 中的图就可以很好地说明清楚了。
假设提交线图在执行 pull 前是这样的：
如果是执行 git pull 后，提交线图会变成这样：
结果多出了 H 这个没必要的提交记录。如果是执行 git pull --rebase 的话，提交线图就会变成这样：
F G 两个提交通过 rebase 方式重新拼接在 C 之后，多余的分叉去掉了，目的达到。
##结论：
大多数时候，使用 git pull --rebase 是为了使提交线图更好看，从而方便 code review。
不过，如果你对使用 git 还不是十分熟练的话，我的建议是 git pull --rebase 多练习几次之后再使用，因为 rebase 在 git 中，算得上是『危险行为』。
另外，还需注意的是，使用 git pull --rebase 比直接 pull 容易导致冲突的产生，如果预期冲突比较多的话，建议还是直接 pull。
Linux公社的RSS地址：https://www.linuxidc.com/rssFeed.aspx