git pull --rebase vs git rebase:危险是什么？

Question

我不明白之间的差别git pull --rebase,并git rebase没有任何其他选择.

我不明白他们是安全的,良好的做法,还是非常危险的.

我可以git pull --rebase在当地做一个破坏历史的承诺吗？

Answer 1

我不建议根据私人分支进行变基.通过私人我的意思是,你可以肯定只有你有拉树枝.

rebase将分支的起始点更改为某个较新的提交,从而将所有提交合并到该点.这可能会导致与其存储库中存在旧分支基础的人员发生合并冲突.我总是建议使用简单合并,并且只为某些情况(例如特征分支)留下变基.

关于你的问题:

那么， git pull --rebase 是否安全？ (2认同)
git pull 的帮助在 --rebase 选项下提到了这一点：“当为 true 时，在获取后将当前分支重新设置为上游分支之上。如果存在与上游分支对应的远程跟踪分支，并且上游分支已重新设置基础自上次获取以来，变基使用该信息来避免变基非本地更改。” 据我所知，如果您运行 git fetch 然后运行 git rebase，则不会将远程更改合并到您的分支中。你可以使用 git pull --rebase 来完成。 (2认同)

Answer 2

git pull --rebase是一个简写git fetch,然后是一个简单的git rebase,而不是默认的git merge.实际的区别在于,只应用后者不会在重新设置代码之前从远程提取任何新的提交,因为它只会考虑您的本地存储库已经知道的内容.

值得一提的是,合并冲突的出现方式与常规git pull相同.

好的，这篇文章解释了 `pull --rebase` 和 `fetch` + `rebase` 之间的一些区别 -https://gitolite.com/git-pull--rebase (3认同)