我正在合并一个可能有很多冲突的远程分支机构。我怎么知道它是否会有冲突?
我没看到任何类似于,git合并的预演。
我正在合并一个可能有很多冲突的远程分支机构。我怎么知道它是否会有冲突?
我没看到任何类似于,git合并的预演。
当前回答
我只需要实现一个自动查找存储库与其远程存储库之间冲突的方法。这个解决方案在内存中进行合并,所以它不会影响索引,也不会影响工作树。我认为这是解决这个问题最安全的方法。下面是它的工作原理:
将远程获取到存储库。例如: Git获取源主机 执行命令git merge-base: git merge-base FETCH_HEAD master 运行git merge-tree: git merge-tree mergebase master FETCH_HEAD (mergebase为上一步打印的merge-base十六进制id)
现在假设您想要合并远程主服务器和本地主服务器,但是您可以使用任何分支。Git合并树将在内存中执行合并,并将结果打印到标准输出。Grep模式<<或>>。或者您可以将输出打印到一个文件中并进行检查。如果你发现一行以“changed in both”开头,那么很可能会有冲突。
其他回答
我猜你只是想知道在真正尝试合并之前你给自己惹了多少麻烦……并且在合并失败后重置到最后一次提交相对容易,所以如果这是预期的方法,我不会感到惊讶。
也就是说,如果你真的不想触及工作树中现有的文件,你可以创建一个补丁并针对目标分支测试它。这还可以显示对哪些文件做了哪些更改-只需在文本编辑器中打开补丁文件。
git checkout -b mycrazybranch
[change some stuff...]
git add .
git commit -m "changed some stuff"
git format-patch master --stdout > crazy.patch
git checkout master
git apply crazy.patch --check
[all good! cleanup...]
rm crazy.patch
如您所见,这将创建一个补丁文件,然后您可以测试它—检查并查看是否有任何错误,然后删除补丁文件。
我的简单粗暴解决方案是:
创建一个“pre-master”分支(当然来自master) 将所有你想要的东西合并到这个预master中。 然后你可以看到合并是如何发生的,而不触及主。 将pre-master合并为master OR 将所有想要发布的分支合并到master中
不管怎样,我会听从@orange80的建议。
如果你想从B快进到A,那么你必须确保git log B..A没有显示任何东西,也就是说A没有B没有的东西。但即使B. A有一些东西,你仍然可能能够合并而没有冲突,所以上面说明了两件事:将会有一个快进,因此你不会得到冲突。
我只想看到冲突(不能看到他们与diff3在GitHub,还)。充分利用上面的答案,我想到了这个:
git merge --no-commit --no-ff @{upstream}
git grep -l '<<<<<<< HEAD' | xargs -I % sh -c "echo -e '\n\e[93m%\n---\e[0m' && cat %"
git merge --abort
对我来说,这是用来检查我的pr的。你可以用任何分支替换@{upstream}。
我希望这对大家有所帮助。
我很惊讶没有人建议使用补丁。
假设你想测试从your_branch到master的合并(我假设你已经检查了master):
$ git diff master your_branch > your_branch.patch
$ git apply --check your_branch.patch
$ rm your_branch.patch
这样应该可以了。
如果你得到这样的错误
error: patch failed: test.txt:1
error: test.txt: patch does not apply
这意味着补丁并不成功,合并会产生冲突。没有输出意味着补丁是干净的,您可以轻松地合并分支
请注意,这实际上不会改变您的工作树(当然除了创建补丁文件,但您可以安全地删除之后)。在git-apply文档中:
--check
Instead of applying the patch, see if the patch is applicable to the
current working tree and/or the index file and detects errors. Turns
off "apply".
提醒那些比我更聪明/对git更有经验的人:如果我错了,请告诉我,这个方法确实显示出与常规合并不同的行为。奇怪的是,这个问题已经存在8年多了,没有人会提出这个看似显而易见的解决方案。