git 手动master_如何在Git中手动合并所有文件？

我想用meld或任何其他diff工具手动合并所有文件，我如何用git来完成这项工作？< BR>当我运行git mergetool时上面写着no files need merging。所以我想只有在我有冲突的时候我才能做到。

请为我们提供一些您想要合并的内容以及不希望自动完成此操作的原因。

我想合并文本文件：)我习惯了Mercurial的手动合并，喜欢同时查看3个文件，如果出了问题，我总是可以自己编辑所有文件。

是否要合并同一文本文件的不同修订版本的不同文本文件？这些文件如何与Git相关？

在我的案例中，相同文本文件的不同修订

所以，如果两个分支都修改一个给定的文件，即使它在完全不同的区域中，所以自动合并可以正常工作，那么您想手动合并它吗？

是的，我想在某些情况下手动合并，因为在这种情况下，我知道一切都按我想要的进行，而不是按应用程序的决定进行。

如果发生自动合并和修复问题怎么办？

@据我所知，这不再是可用的方案，当检测到冲突时，Git不再允许自动合并。

有更简单的方法：

git merge --no-commit merge_branch。

正如人们所说：

With --no-commit perform the merge but pretend the merge failed and do

not autocommit, to give the user a chance to inspect and further tweak

the merge result before

committing.

号

谢谢您。是否有一种方法可以使用mergetool/meld以一个良好的三向接口来逐段地检查和合并更改？

通过添加--no-ff，快速转发被禁用，如果没有冲突，这将发生。

当然，如果有冲突，使用git mergetool。

我曾经有过这样一个场景：

git merge --no-commit merge_branch

号

刚刚导致了一个快速前进。

如果发生这种情况，您可以使用：

git merge --no-commit --no-ff merge_branch

然后您就可以查看您的更改了

可以用同样的方法拉它吗？如果无法快速前进，我需要手动验证所有冲突。

@最大值否，但由于pull只是fetch和merge的组合，所以先调用git fetch merge_branch，后调用merge。

使用两个--no-commit --no-ff就像在包含* -merge的根目录中有.gitattributes文件，但是根据merge选择是否使用它。

一个类似的问题是如何防止使用git的自动合并？

分形空间给出了一个我认为有用的答案：

$ git checkout master

$ git difftool -t kdiff3 local-branch HEAD

其想法是使用difftools而不是自动合并工具来手动选择所需内容并创建新文件。

我添加了一个答案，将这个答案与git merge的答案进行比较，以帮助其他任何一个偶然进入此页面的人澄清问题。

注意，如果您坚持手动合并(可能对于某类文件)，您仍然可以定义合并驱动程序。在"Git-如何强制合并冲突和手动合并所选文件"中有一个具体的例子。

这样，合并驱动程序脚本就可以调用所需的任何合并工具。

如果有人来这里想知道@true使用git difftool的答案与使用git merge的其他答案之间的区别，请参阅git mergetool vs difftool。

简而言之，如果Git配置为使用现代diff.tool，如kdiff3、meld或vimdiff，则可以使用diff工具本身手动合并不同的文件，并且命令行可以很简单：

git difftool other_branch

。

…这将允许您在当前分支和其他分支之间进行双向手动合并(在man git-config中称为$local和$remote)。

其他答案讨论的"正确"方式是将git配置为使用，例如kdiff3或vimdiff作为您的merge.tool，并使用：

git merge --no-commit --no-ff other_branch

git mergetool

…此命令可以在$base、$local和$remote之间执行N向手动合并，合并为$merged。有关如何配置Git的示例，请参阅https://stackoverflow.com/a/2235841/1264797。如果您使用Git已经知道的工具之一，那么您很多人根本不需要配置mergetool.*.cmd条目。(meld只能显示三个窗格，因此如果将meld与默认设置一起使用，将看不到$base。)

有人可能会跳进来纠正我，但除了N向合并能力，这两种方法似乎产生了相同的结果。difftool和mergetool都没有在新提交时添加其他分支作为父级，因此在这两种情况下，合并在例如gitk中并不明显，必须在提交消息中描述(稍后注意)。

我选择了我们的策略(它也存在于tortoisegit中)，在进行了手动差异之后，您已经引入了您想要的手动更改。

来自：https://git-scm.com/docs/merge-strategies网站

The merge mechanism (git merge and git pull commands) allows the backend 'merge strategies' to be chosen with -s option. Some strategies can also take their own options, which can be passed by giving -X arguments to git merge and/or git pull.

ours

This resolves any number of heads, but the resulting tree of the merge

is always that of the current branch head, effectively ignoring all

changes from all other branches. It is meant to be used to supersede

old development history of side branches. Note that this is different

from the -Xours option to the 'recursive' merge strategy.

号

但是BitBucket后来看到的对我来说是个谜，它承认提交是合并，但是实际上合并分支失败(不能解决拉请求)——也许BitBucket专家可以帮助解决这个问题，我甚至不能给你任何日志/错误消息，因为我没有这个可见性——Git/TortoisGit一点也不抱怨。