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, 这就得看公司与项目的规定。
等效命令
- git stash先暂存代码
git pull拉到最新
git add并commit
总结
在提交代码前如果无法拉取最新代码，除了可以使用git stash暂存，还可以使用git commit配合git pull --rebase提交代码，最终达到减少代码”不良记录“的目的
参考文章
blog.csdn.net
