【问题标题】:git pull --rebase on a remote branchgit pull --rebase 在远程分支上
【发布时间】:2016-05-03 02:56:27
【问题描述】:

我有一个与git pull --rebase 命令相关的问题:为什么在远程分支上使用git pull --rebase 不是一个好主意?我知道 rebase 命令会重写历史记录。但是为什么(以及如何以及在何种情况下)这个命令可能是邪恶的?

【问题讨论】:

标签: git git-rebase git-pull


【解决方案1】:

我不知道这个想法从何而来,在远程分支上使用git pull --rebase 特别邪恶。

开头没有多大意义:git pull按设计处理远程存储库,以及远程分支。没有办法将它与非远程分支一起使用。

git pull --rebase 在本地工作较长时间并希望从远程存储库重复合并更改而不创建太多合并提交时特别有用。是在本地未发布分支上使用git pull --rebase还是只使用git pull只是个人喜好。

与往常一样:永远不要对已发布的提交进行变基,你很好。无论您如何执行变基(无论是使用git pull --rebase 还是显式git rebase

【讨论】:

  • 也许我不清楚:我们正在使用基于功能或故事的远程分支。在这一点上,不要理解“永远不要重新发布已发布的提交”这一点。我如何重新发布已发布的提交?我做了一些工作,提交了一些代码并执行了 'git pull --rebase' 我自己的提交没有在这一点上发布。因此我不能重新发布(推送)提交。
  • 您的工作流程是什么并不重要。如果您对已发布的提交进行变基,则您正在创建新的不兼容的提交对象,因此您正在破坏拥有原始提交的每个人。已发布意味着您在之前的某个时间点推送过它们。如果您没有推送它们,即没有其他人拥有它们,那么重新设置它们就没有问题。
  • 好的,现在我想我明白了。变基会影响“delta”提交。如果这些提交(比如说:E、F、G...)之前被推送,现在被重新设置为 E'、F'、G',那么可能会出现问题。但是,如果我 rebase 我的本地 repo 和提交,不在远程分支中,它应该没问题?!
  • 是的,重新定位未发布的提交完全没问题,而且真的不应该有问题,因为反正没人知道它们。
猜你喜欢
  • 1970-01-01
  • 2012-03-24
  • 1970-01-01
  • 2020-04-04
  • 2015-05-02
  • 1970-01-01
  • 2012-01-16
  • 2016-05-02
  • 2012-07-18
相关资源
最近更新 更多