gpt4 book ai didi

git - 什么时候应该使用 git pull --rebase?

转载 作者:IT王子 更新时间:2023-10-29 01:08:40 24 4
gpt4 key购买 nike

我知道有些人默认使用 git pull --rebase 而其他人则坚持从不使用它。我相信我理解 merge 和 rebase 之间的区别,但我试图将其放在 git pull 的上下文中。只是不想看到很多 merge 提交消息,还是有其他问题?

最佳答案

我想就 git pull --rebase 的实际含义提供一个不同的视角,因为它有时似乎会迷失。

如果您曾经使用过 Subversion(或 CVS),您可能已经习惯了 svn update 的行为。如果您有更改要提交并且由于上游已进行更改而导致提交失败,则您 svn update。 Subversion 通过将上游更改与您的更改 merge 来进行,这可能会导致冲突。

Subversion 所做的,本质上是 git pull --rebase。重新制定本地更改以相对于较新版本的行为是它的“ rebase ”部分。如果您在失败的提交尝试之前完成了 svn diff,并将生成的差异与之后的 svn diff 的输出进行比较,则两个差异之间的差异就是 rebase 操作做到了。

在这种情况下,Git 和 Subversion 之间的主要区别在于,在 Subversion 中,“您的”更改仅作为工作副本中的未提交更改存在,而在 Git 中,您在本地有实际提交。换句话说,在 Git 中你 fork 了历史;你们的历史和上游的历史不同,但你们有共同的祖先。

在我看来,在让本地分支简单地反射(reflect)上游分支并对其进行持续开发的正常情况下,正确的做法始终是 --rebase,因为这就是你在语义上实际上是在做。你和其他人正在破解一个分支的预期线性历史。其他人碰巧在你尝试推送之前稍微推送了这一事实是无关紧要的,而且每次这样的时间意外都会导致历史 merge ,这似乎适得其反。

如果您出于某种原因真的觉得有必要将某个东西作为一个分支,那么我认为这是一个不同的问题。但是,除非您有一个明确而积极的愿望以 merge 的形式表示您的更改,否则在我看来,默认行为应该是 git pull --rebase

请考虑其他需要观察和了解您的项目历史的人。您是希望历史上到处都是数百次 merge ,还是只想要代表有意不同开发工作的真正 merge 的精选少数 merge ?

关于git - 什么时候应该使用 git pull --rebase?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2472254/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com