git pull与git pull --rebase

aliases: []
tags: [git]

link:

date: 2022-08-30

目录

• git pull --rebase
• 等效命令
• 总结
• 参考文章

git pull --rebase

在 push 代码时，会提示使用 git pull 命令，也就是拉取远端代码，更新我们的仓库，那么为什么又要加个 --rebase 命令呢？下面来说说这个问题，先从这两命令开始。

git pull = git fetch + git merge FETCH_HEAD

git pull --rebase =  git fetch + git rebase FETCH_HEAD

二者的区别是，在 fetch 之后的操作不同，merge 与 rebase 的不同。

假设当前 master 的提交如下：

如果是你或者你的同事在 cid2 点，开发进度是 cid20(或者突然撇出一个分支，假设是 tmp 分支），此时要把 cid20 提交到 master

在 master 执行 git merge tmp, 然后会得到如下结果：

那么来看看 git rebase,  在 master 执行 git rebase tmp，操作之后的分支如下：

二者对比可知，rebase 没有产生新的节点，使用 rebase 的 git 演进路线 (提交树) 是一直向前的，这样在版本回退时也很容易，用 merge 的 git 路线是跳跃的，如果版本回退你也找不到自己想要的版本，如果在 merge 时出现了冲突那就麻烦了，当前 merge 就不能继续进行下去，需要手动修改冲突内容后，add，commit, push. 而 rebase 操作的话，会中断 rebase, 进入rebasing状态，这时我们需要解决冲突后执行git add，然后执行git rebase --continue直至冲突解决完毕，自动退出rebasing状态，再 push.

想要更好的提交树，建议使用 rebase 操作会更好一点，这样可以线性的看到每一次提交，并且没有增加提交节点。不过也有些项目，不建议使用 rebase, 这就得看公司与项目的规定。

等效命令

1. git stash先暂存代码
2. git pull拉到最新
3. git add并commit

总结

在提交代码前如果无法拉取最新代码，除了可以使用git stash暂存，还可以使用git commit配合git pull --rebase提交代码，最终达到减少代码”不良记录“的目的

参考文章

blog.csdn.net