相关疑难解决方法(0)

我正在使用beanstalkapp,我看到一个分支前面的冲突,只是冲突不是很有帮助.但即使我这样做git status,我也没有看到任何说有冲突的东西.任何帮助,以找到我在哪里可以找到文件冲突？

我想知道在运行merge命令之前是否通过"快进"解析特定合并.

我知道我可以通过"快进"(使用--no-ff选项)专门请求合并不能解决.或者我可以尝试仅通过快进(使用--ff选项)来解决合并.

但有时我想知道在运行它之前是否会通过快进解决特定的合并.我意识到理论上我可以通过挖掘历史树来解决这个问题.而且我也意识到我可以运行合并,看看会发生什么,但如果我决定我更倾向于以其他方式解决合并,这就成了问题,因为我必须撤消合并(通过重新分配分支标签)在ref-log中)并再次执行.

注意:--dry-run问题(是否存在git-merge --dry-run选项？)更多的是关于查看合并中可能存在哪些合并冲突,而不是关于可能通过快进解决的合并.

有没有一种简单的方法可以使用git命令检测两个分支之间潜在的合并/变基冲突？例如，某些文件都在两个分支中被修改，或者某些文件从一个分支中删除而在另一个分支中可用。我能想象的是用命令找到两个分支的共同祖先

git merge-base

然后列出从公共祖先到两个分支头的所有文件更改状态，然后比较状态列表以找出潜在的合并点。这是正确的方法还是更聪明的东西存在？如果是这样，如何实现呢？

非常感谢。

我想测试一下一个分支是否可以合并到另一个分支中。例如，假设我想测试一个发布分支是否可以合并到 master 中，而不需要实际合并到 master 中。我想我会做这样的事情：

#!/usr/env/bin bash
git checkout master
git checkout -b master_temp
git merge my_release_branch

所以我认为如果退出代码为0，则合并成功，否则合并失败。

不过，这是我最关心的问题：假设合并成功，但它打开了交互部分。我怎样才能避免这种互动呢？有时在合并nano或vim打开期间，我们必须做一些事情（不确定做什么）。有办法把它关掉吗？

这个问题基本上是一样的，但是，这个问题并没有规定这需要由人类以外的任何人来完成。就我而言，它需要是自动/程序化的。

我想以编程方式确定我的功能分支是否会有rebase冲突,如果我试图改变它们.有没有办法让git在没有实际执行rebase的情况下告诉我这些信息？

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

我的问题类似于这两个,它们是相同的,但是用于合并而不是rebase

• git可以告诉我合并是否会在没有实际合并的情况下发生冲突？

• 有没有git-merge --dry-run选项？