我有一组调试实用程序位于 git stash 插槽中;我在分支之间移动,这些分支在存储变化方面仅略有不同。我git stash apply
在相应分支的顶部存储以测试功能。
但是我在其中一个分支中遇到了适当的合并冲突,但我想更喜欢存储中的内容,所以我希望合并策略“递归”更喜欢来自存储的版本(我猜那是“他们的”,参见man git-merge
第节MERGE-STRATEGIES
,小节recursive
)。
我能以某种方式告诉git stash apply
使用什么合并策略吗?
是的,您可以自己进行合并。存储提交名为stash
.
git cherry-pick -n -m1 -Xtheirs stash
Cherrypick 以cherrypick 的父级为基础进行合并。存储提交记录了具有两个父级的工作树状态,签出提交和存储索引。
告诉cherrypick 使用第-m1
一个父级作为合并基础,因为这里对于您想要合并的确切更改存在任何歧义。-n
说不提交结果。
这将生成一个工作树和索引,其中的更改与隐藏的工作树中的更改相匹配。相反,如果您想在隐藏索引中应用更改,请改为使用cherrypick stash^2
;或者,如果您想将隐藏索引(即添加的 aka 暂存 aka 索引内容)的更改应用到隐藏的工作树,请使用-m2
而不是-m1
.
如果您只想合并到工作树,请执行
savetree=`git write-tree`
git cherry-pick -n -m1 -Xtheirs stash
git read-tree $savetree
这足以处理此处问题中的情况(应用一组方便的更改),但它并不能完全重现 stash 为您所做的一切。仅将隐藏的索引更改应用于当前索引,而将隐藏的工作树更改仅应用于当前工作树只是简单的挑剔。 如果有人想看到它,它git stash
是一个脚本。/usr/libexec/git-core/git-stash
不,不修改stash
脚本(您会在git-core
目录中找到它)。
我不会这样做,而是将存储库变成一个真正的分支。这将:git stash branch newbranch [stash-id]
git checkout -b newbranch
apply --index
和(成功时,应该总是)drop
藏匿处。git stash save
(如果您想将其作为存储区保留,则可以通过 -ing 立即恢复该存储区,然后git stash apply --index
将其在新分支上重新生效。)
此时,您可以根据需要/希望提交索引和/或提交新的工作目录,和/或在新分支上大惊小怪,然后您就有了一个可以合并的“真正的分支”。
我遇到了同样的问题,最终使用了一个带有临时分支的复杂过程。IMO,如果 stash 命令将 -X 参数传递给 merge 命令,则可以轻松解决此问题。认为这是一个丑陋的解决方法。
净效果:将 stash 应用到当前 master,丢弃任何有利于 stash 中的差异。
按照@torek 的建议,为存储创建一个临时分支。
git stash branch tmp [stash-id]
检查您的更改。使用任何消息,因为此提交不会是永久性的。
git add --all .
git commit -m 'tmp commit'
tmp
使用“我们的”合并策略将分支重新定位到您的目的地
git rebase -X ours master
重置临时提交,将更改添加到当前索引
git reset HEAD^
清理临时分支
git checkout master
git branch -d tmp
当 stash 和 master 都包含一些相同的更改时(例如,如果合作者和您都重命名文件),这会非常方便。