跳至正文

记录几个git的知识点

  • Linux

git

我们项目用svn比较多,最近在做一些git的尝试,之前对git一知半解,属于能用但不太懂,仔细看下来确实git比svn复杂不少。

rebase和merge的差异

参考文章:

  1. https://blog.csdn.net/u010698107/article/details/129000177
  2. https://dingjingmaster.github.io/2022/05/0002-rebase%E4%B8%8Emerge%E7%9A%84%E5%8C%BA%E5%88%AB/

是用git的开发方式通常是这样:
file
从master分支拉取一个自己的开发分支,然后自己会开发对应的内容,开发完成之后通常其他人也对master进行了提交,这个时候就会出现这样的分支情况:
file
我在feature分支肯定不能直接提交在master分支上了,这里就有两个思路,一个是把master最新的两个提交C3, C4也merge到C6这里,进而产生一个新的提交,如下所示:
file
这就是merge,但是对于git我们通常不这么干,我们通常做的事情是rebase,即将c3, c4的提交插入在C5之前:
file

上面这就是rebase和merge的差异。
但是有一个很重要的协作法则,rebase不要用在公共协作分支上。如第二篇参考文章中提到的,如果我rebase了一个公共分支之后,其他同学在这个分支上也有提交,那么彼此之间就需要大量的merge而且混乱,那不如直接merge。

pull和fetch的差异

简单地说git pull包含了git fetch && git merge。
git fetch主要是为了从远程仓库获取最新的代码,例如将仓库的代码拉到origin/master中,这个操作不会影响本地分支,通常git fetch之后还要做一些其他的工作,例如rebase,merge之类,所以开发了一个简化的指令pull。

git pull就基本上是等价于快速地进行一次合并,所以默认行为是merge,可能需要手动处理冲突,同时也可以在pull中使用–rebase参数将merge操作改成rebase操作:

git pull origin master  # 相当于git fetch origin master + git merge origin/master current_brance
git pull --rebase origin master # 相当于 git fetch origin master + git rebase master

所有参考文章:

https://blog.csdn.net/u010698107/article/details/129000177
https://dingjingmaster.github.io/2022/05/0002-rebase%E4%B8%8Emerge%E7%9A%84%E5%8C%BA%E5%88%AB/#git-rebase-%E5%8E%9F%E7%90%86
https://cloud.baidu.com/article/3318148

End。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

目录