1

我有以下 bash 脚本：

git merge --squash -Xtheirs dev -m "squashing" && 
(./test/testsrc/shell/node-c.sh && echo "compiled successfully") || (git reset --hard; exit 1)

我有两个问题：

  1. 如果合并失败，是否需要执行 git reset 才能恢复到合并开始之前的状态？
  2. 假设 1 的答案是“是”，那么上面的脚本是否正确，这样如果 node-c.sh 脚本以非零代码退出，则 git reset --hard 将被调用并且绝对会以 code = 退出1？

我在想，在运行 git merge 时，无论如何都会更新索引，因此 git reset --hard 始终是正确的做法。

顺便说一句，我看到似乎是一些糟糕的 Git 错误，其中合并不起作用并生成 .js 文件，这些文件会被破坏，而且通常甚至无法通过使用“$ node -c”进行编译。不确定是否有人以前见过这个，但我已经向 Git 提交了错误报告。

4

2 回答 2

3

如果合并失败，您将与分支处于冲突状态。我对此的想法是，使用而不是更安全，因为：git merge --abortgit reset --hard

  • 从命令的上下文中可以清楚地看出，您只是在中止合并，并且
  • 在 Git 的阶段可能会出现一些由于合并失败而永远丢失的东西

您不想在没有某种人工/人工干预的情况下硬重置分支；即使你正在重置的东西可能是安全的，你仍然在玩钚。

至于你的 Git “bug”——我真的怀疑 Git 应该受到指责；这可能是预期合并未按计划进行以及 Git 需要您帮助它的副作用。

于 2016-12-15T21:56:20.053 回答
1

在您的脚本中，您实际上应该这样做：

git merge --squash -Xtheirs dev -m "squashing" && 
(./test/testsrc/shell/node-c.sh && echo "compiled successfully") ||
(git reset --hard ORIG_HEAD; exit 1)

当合并通过但node-c.sh没有通过时，则您有一个您不想要的合并提交。伪引用ORIG_HEAD指向最近一次合并开始时您所在的位置：如果合并失败，则与 相同HEAD，成功时与 相同HEAD^。

于 2016-12-15T22:01:44.123 回答