"git pull"可以自动存储并弹出挂起的更改吗？

Question

我知道如何解决这个问题:

user@host$ git pull
Updating 9386059..6e3ffde
error: Your local changes to the following files would be overwritten by merge:
    foo.bar
Please, commit your changes or stash them before you can merge.
Aborting

但是,是不是有办法让git pull做stash和pop舞蹈给我吗？

如果此命令具有不同的名称,则可以.

创建shell别名git stash; git pull; git stash pop是一种解决方案,但我寻找更好的解决方案.

Answer 1

适用于Git 2.6+(2015年9月28日发布)

唯一git config感兴趣的设置是:

rebase.autoStash

设置为true时,在操作开始之前自动创建临时存储,并在操作结束后应用它.
这意味着您可以在脏工作树上运行rebase.

但是,谨慎使用:成功重组后的最终存储应用程序可能会导致非平凡的冲突.默认为false.

结合以下:

pull.rebase

如果为true,则rebase在获取的分支顶部分支,而不是在运行"git pull"时合并默认远程的默认分支.

git config pull.rebase true
git config rebase.autoStash true

git pull即使在肮脏的树中,这对于简单的工作也足够了.
在这种情况下不需要别名.

请参阅Kevin Daudt()提交的53c76dc(2015年7月4日).^{(由Junio C Hamano合并- -在提交e69b408,2015年8月17日)}Ikke
gitster

pull:rebase.autostash启用时允许脏树

rebase在遇到脏工作树时学会了隐藏更改,但却git pull --rebase没有.

仅在rebase.autostash未启用时验证工作树是否为脏.

注意:如果你想在不使用自动暂存的情况下进行拉动(即使rebase.autoStash true设置了),那么你就可以使用git 2.9(2016年6月):

 pull --rebase --no-autostash

请参阅提交450dd1d,提交1662297,提交44a59ff,提交5c82bcd,提交6ddc97c,提交eff960b,提交efa195d(2016年4月2日),并提交f66398e,提交c48d73b(2016年3月21日)由Mehul Jain(mehul2029).
^{(由Junio C gitsterHamano合并- -在提交7c137bb,2016年4月13日)}

提交f66398e特别包括:

pull --rebase:添加--[no-]autostash标志

如果rebase.autoStash设置了配置变量,则无法git pull --rebase从命令行覆盖" ".

教" git pull --rebase" --[no-]autostash命令行标志,它会覆盖当前值(rebase.autoStash如果已设置).由于" git rebase"理解该--[no-]autostash选项,所以只需将选项传递给基础" git rebase",当git pull --rebase调用" "时.

警告:在Git 2.14(2017年第3季度)之前,git pull --rebase --autostash当本地历史快速转发到上游时," "没有自动存储.

请参阅Tyler Brazier()提交f15e7cf(2017年6月1日).^{(通过合并JUNIOÇ滨野- -在提交35898ea,2017年6月5日)}tylerbrazier
gitster

pull:ff --rebase --autostash在脏回购中工作

当git pull --rebase --autostash在一个脏的存储库中导致快进时,没有任何东西被自动释放并且拉动失败.
这是因为当我们可以快进时避免运行rebase的快捷方式,但在该代码路径上忽略了自动转发.

更新:马里乌什Pawelski要求在评论一个有趣的问题:

因此,每个人都在写关于autostash什么时候进行rebase(或pull --rebase).

但是,当您使用合并进行正常拉动时,没有人会采取自动消除.
那么没有自动切换？或者我错过了什么？我更喜欢这样做,git pull --rebase但OP询问" 标准 "git pull

回答:

讨论这个自动暂存功能的原始线程,最初都是为git pull(merge)和git pull --rebase.实现的.

但是...... Junio C Hamano(Git maintainer)指出:

如果pull-merge这会导致触发此主题的"烦恼",根据定义,本地更改与合并重叠,并且此内部"隐藏弹出"将触及合并所触及的路径,并且可能不会导致"丢弃" "但要留下进一步的冲突来解决.

我怀疑pull.autostash配置不是一个很好的补充,因为它鼓励了一个糟糕的,引起痛苦的工作流程.
在简单的情况下,它可能不会受到伤害,但是当局部变化很复杂时,它会比没有它更容易受到伤害,并且配置会激发选择的动机.

"pull-rebase"的等式有点不同,因为"rebase"坚持你从干净的工作树开始,所以"下载然后停止"烦恼感觉更大.我怀疑放松可能是解决真正问题的更有效方法.

因此,对于经典的拉式合并,最好是:

鼓励用户在运行" git pull" 之前考虑他在工作树中具有的WIP的性质.
它是一个太复杂的野兽,可能会干扰别人在做什么,或者是一个微不足道的变化,他可以藏匿并弹回它？

如果是前者,他会更好地做" checkout -b",继续工作直到局部变化进入一些更好的形状和"提交",然后进入原始分支.

如果是后者,他最好做的事情是:

• " git pull",
• 找到冲突后,运行
  • git stash,
  • git merge FETCH_HEAD 和
  • git stash pop

Answer 2

为迎面而来的探险家节省几秒钟,这是一个总结(感谢@VonC):

git pull --rebase --autostash

Answer 3

如上面的评论所述,设置两个配置值当前不起作用git pull,因为autostash配置仅适用于实际的rebase.这些git命令可以满足您的需求:

git fetch
git rebase --autostash FETCH_HEAD

或者将其设置为别名:

git config alias.pullr '!git fetch; git rebase --autostash FETCH_HEAD'

然后做:

git pullr

当然,可以根据需要重命名该别名.

Answer 4

使用Git 2.6+,您可以使用以下内容:

alias gup='git -c rebase.autoStash=true pull --rebase'

这--rebase使得git-pull使用rebase而不是merge,所以设置/选项--ff-only不适用.

我--ff-only默认使用别名来拉(git pull --ff-only),然后可以使用gup(从上面)以防无法快进合并或存在隐藏的更改.