git - git pull --rebase 根本不容忍任何修改过的文件，这与 git pull --no-rebase 相反

Question

请注意：

C:\xyz\55 [release/r-855 ↓1 +0 ~16 -0 !]> git pull --rebase
error: cannot pull with rebase: You have unstaged changes.
error: please commit or stash them.
C:\xyz\55 [release/r-855 ↓1 +0 ~16 -0 !]> git pull --no-rebase
From http://server.xyz.com:8080/tfs/defaultcollection/code/_git/xyz
 * [new branch]          wfm/tfs485759 -> origin/wfm/tfs485759
Updating 5f010c356..871eb9ca2
Fast-forward
 .../PayrollService/DAL/Payroll/PayRunDataProviderDAL.cs            | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
C:\xyz\55 [release/r-855 ≡ +0 ~16 -0 !]>

我的结论是git pull --rebase根本不容忍任何修改过的文件。这与 不同git pull --no-rebase，只要修改后的文件不与新提交发生冲突，就可以了。

这有点糟糕。

我的结论正确吗？或者可以配置为在修改文件时git pull --rebase表现得更像？--no-rebase

标签： git

Answer 1

git rebase，与git merge（通过正常拉动完成）相反，需要干净的工作树。
（git merge只要求合并的文件当前没有被修改）

要自动获得干净的工作树，请使用git config --global rebase.autostash true.
这样，你的git pull --rebase意志就会奏效。

---

警告：

当远程历史是我们历史的后代时，“ git pull --rebase” ^（man）忽略了配置变量，这已在 Git 2.36（2022 年第二季度）中得到纠正。rebase.autostash

请参阅Philippe Blain ( ) 的提交 3013d98（2022 年 1 月 13 日）。^{（由Junio C Hamano 合并——在提交 7a9ae6d中，2022 年 2 月 5 日）}phil-blain
gitster

pull --rebaserebase.autostash:快进时的荣誉

^{报道人：Tilman Vogel
帮助人：Junio C Hamano
签字人：Philippe Blain}

pull --rebase当其他历史是我们的后代（即
执行快进）时， “ ”在内部使用合并机制。
这来自这个线程，讨论是从一个功能请求开始的。

在讨论中阅读其背后的基本原理有点困难，但对于所有相关人员来说，这似乎是一个既定事实，甚至不需要提及使用“rebase”完成的快速转发比使用“rebase”完成的要好得多“合并”，更重要的是，“合并”留下的结果与“变基”一样好（或优于）。

除了一件事。

因为 " git merge" ^{( man )}不（也不应该）尊重rebase.autostash，所以 " " ^{( man )}在快进过程中用作（希望更好）替代 " git pull" ^{( man )}时需要阅读并转发它。git mergegit rebase

但是我们忘记了这样做（我们只在使用“命令行选项”调用自身时将“ --[no-]autostash”添加到“ git merge”命令中。git pull--[no-]autostash

确保 " git merge" 运行 git 并设置了--autostashwhenrebase.autostash并用于代表 rebase 快进历史记录"。

顺便说一句，此更改还涉及以下情况

• " git pull --rebase" ^{( man )} (没有其他命令行选项) 运行
• " rebase.autostash" 未设置
• 历史快进

在这种情况下，“ git merge”以显式方式运行，--no-autostash以防止它遵守merge.autostash配置，这正是我们想要的。
毕竟，我们希望“ ”在被用于此目的时git merge假装它是。git rebase