git 可以告诉我 rebase 是否会在没有实际 rebase 的情况下发生冲突？答案

【问题标题】：Can git tell me if a rebase will conflict without actually rebasing?git 可以告诉我 rebase 是否会在没有实际 rebase 的情况下发生冲突？
【发布时间】：2017-07-06 15:25:02
【问题描述】：

我想以编程方式确定我的功能分支是否会在我尝试对它们进行变基时发生变基冲突。有没有办法让 git 在不实际执行变基的情况下告诉我这些信息？

如果做不到这一点，在git rebase --aborting 之前检测变基是否失败的最简单方法是什么？

我的问题与这两个类似，但它们是相同的，但用于合并而不是变基

【问题讨论】：

标签： git rebase

【解决方案1】：

有没有办法让 git 告诉我这些信息而无需实际执行变基？

简短的回答是“不”。长答案更长，但以“否”结尾:-) ...您可以通过编写大量代码来非常接近，但要获得完整正确的答案，您必须执行 rebase 的所有提交复制步骤，其中点你不妨只运行变基。

如果做不到这一点，在git rebase --aborting 之前检测变基是否失败的最简单方法是什么？

如果变基成功完成，git rebase 命令返回成功（零）退出代码，否则返回失败（非零）退出代码。在 shell 脚本中，你可以使用git rebase $args || git rebase --abort。

【讨论】：

这里有很多很好的答案。谢谢大家。我根据年龄和全面性选择了答案。

【解决方案2】：

基于answer of SVSchmidt，你可以扩展他的第一个命令，即使在成功的情况下也可以恢复：

git rebase master && (echo "Success" && git reset --hard ORIG_HEAD) || (echo "Fail" && git rebase --abort)

这仍然会运行变基，但是在成功的情况下将您的HEAD 重置为变基之前的旧HEAD。产生的提交和 reflog 的更改将保留，只有您的分支的引用被重置。

您可能希望为命令的输出添加重定向以避免不必要的输出。这样做时请记住，rebase 可能由于合并冲突以外的其他情况而失败，例如工作目录中未暂存的更改。

【讨论】：

reset 不“撤消”变基。它将参考返回到以前的状态；但 rebase 也会创建新对象并更新 reflogs - 这两者都没有撤消
谢谢，你是对的。我已经编辑了我的答案，以更好地描述重置将改变什么以及仍然保留什么。

【解决方案3】：

如果做不到这一点，在 git rebase --aborting 之前检测 rebase 是否失败的最简单方法是什么？

git rebase 在失败时返回一个虚假状态，所以你可以做类似的事情

git rebase feature && echo "Success" || echo "fail" && git rebase --abort

但是，这将在成功时执行实际的变基。如果你想测试如果rebase 会成功而不实际执行它，恐怕我唯一的想法是检查另一个分支，检查rebase是否成功并且切换回来，例如：

branch=$(git branch | grep '* .*' | sed s/..//); git checkout -b $branch-rebase > /dev/null ; git rebase test-2 > /dev/null && result="Success" || result="fail" ; git rebase --abort ; git checkout $branch ; git branch -D $branch-rebase ; echo $result

我首先在一个变量中记住当前分支（如果有人有更好的确定当前分支的解决方案，请告诉我），切换到branchname-rebase，执行rebase，签出原始在我回显结果之前分支并删除测试分支。哈克，但根据您的用例，这可能有效。

【讨论】：

【解决方案4】：

最接近 rebase 的“试运行”的方法是从分离的 HEAD 状态运行 rebase（这样实际上不会修改 refs）。所以不是

git rebase develop feature_X

你可能会这样做

git rebase develop `git rev-parse feature_x`

并检查退出状态。这种方法的问题是：

1) 这很耗时。基本上对于任何不冲突的分支，整个变基都会运行。（而且很难想象你怎么能做更少的工作并且仍然准确地知道变基是否会成功。）

2) 它会创建冗余对象（悬空提交及其依赖项），这些对象不会可见，但仍会占用本地仓库中的空间，直到您将悬空提交剔除的 reflog 并运行 gc，或者创建一个新的克隆。如果你经常这样做，浪费的空间真的会加起来。

我也不确定这有多少实用性。仅仅因为feature_X 和feature_Y 将各自干净地变基到develop，并不意味着“变基featureX 然后变基featureY”的顺序一定会干净地完成。虽然情况似乎不应该如此，但在我最近看到的一些事情之后，当我得知一些极端情况时，rebase 的顺序决定是否存在冲突时，我不会感到震惊。

因此，充其量你会得到“唾手可得的果实”——“事实上，我知道它们之间存在冲突”。但是，嘿，你知道，如果这是你需要的代码，那么这就是你需要的代码。

【讨论】：

【解决方案5】：

您可以使用自定义预变基挂钩在变基开始之前执行您需要的任何检查。这里有一个示例 pre-rebase 钩子：https://github.com/git/git/blob/master/templates/hooks--pre-rebase.sample

在 pre-rebase 钩子代码中，您可以比较更改的文件并检查冲突并停止 rebase。

【讨论】：

但是检查是什么？他们是我的主要问题。我不知道要检查什么或如何检查。