我想使用 meld 或任何其他 diff 工具手动合并所有文件,如何使用 Git 执行此操作?
当我运行git mergetool
它说no files need merging
。所以我想只有当我有冲突时我才能做到。
7 回答
有更简单的方法:
git merge --no-commit merge_branch
正如男人所说:
--no-commit
执行合并但假装合并失败并且不自动提交,以便用户有机会在提交之前检查并进一步调整合并结果。
我有一个场景:
git merge --no-commit merge_branch
只是引起了快进。
如果发生这种情况,您可以使用:
git merge --no-commit --no-ff merge_branch
然后您就可以查看您的更改
一个类似的问题是如何使用 git 防止自动合并?
FractalSpace 给出了一个我认为有用的答案:
$ git checkout master
$ git difftool -t kdiff3 local-branch HEAD
这个想法是使用 difftools 而不是自动合并工具来手动选择您需要的内容并创建新文件。
对于只需要对合并进行微观管理的任何人,请跳至下面的混合部分。
对于想知道@True 的答案 usinggit difftool
和其他答案之间的区别的人 use git merge
,请参阅Git mergetool vs difftool。
以下是更多详细信息:
差异工具
如果您将 git 配置为使用现代diff.tool
版本,例如 kdiff3、meld 或 vimdiff,您将能够使用该 diff 工具手动合并,并且命令行可以很简单:
git difftool other_branch
...这将让您在当前分支和 other_branch 之间进行双向手动合并(在 中描述为 $LOCAL 和 $REMOTE man git-config
)。
合并工具
其他答案讨论的“正确”方式是将 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 。mergetool.*.cmd
如果您使用 git 已经知道的工具之一,您根本不需要配置条目。(Meld 只能显示三个窗格,因此如果使用默认设置的 meld,您将看不到 $BASE。)
差异工具与合并工具
有人可能会跳进来纠正我,但上述difftool
和mergetool
技术之间的主要区别似乎是:
mergetool
如果相应配置,可以进行 N 路合并mergetool
在新提交中添加 other_branch 作为父级,因此历史记录正常工作difftool
让您手动查看和选择每条更改的行,但您失去了上述两个好处mergetool
混合动力——两全其美
结合合并和差异的方法看起来像这样:
git merge --no-commit --no-ff other_branch
git mergetool
git difftool HEAD
git commit
...这会进行 N 路合并以解决冲突并使历史记录正常工作,然后向您显示完整的差异集,以便您可以在提交之前查看和调整。
我发现其他答案不令人满意,并且在寻找答案时感到沮丧。我终于在这里找到了这个问题的解决方案:https ://stackoverflow.com/a/11593308/1351182
如果您运行这些命令,您将创建一个新的提交,它基本上采用最新的提交branchToMergeFrom
并允许您在其之上应用补丁,我认为这就像在顶部的附加提交。
git checkout branchToMergeTo
git checkout --patch branchToMergeFrom [file]
然后将提示您(如果您未指定,则逐个文件file
)您要合并的确切“帅哥”。通过这种方式,它会引导您完成自动合并过程的每个部分,而是要求手动仲裁您希望从mergefrom
分支接受哪些点和点。这是我的项目中的示例:
@@ -249,7 +251,8 @@ def draw_everything():
draw_bg()
draw_balls(ax)
- plt.show(block=False)
+ if show:
+ plt.show(block=False)
def advance(ms, accel_fun, collision_matrix_fun):
global balls
(3/6) Apply this hunk to index and worktree [y,n,q,a,d,K,j,J,g,/,e,?]?
输入y
and后<Enter>
,我看到了该文件的下一个大块(4/6)
。底部的这个提示让您只需用 接受合并“hunk”,用y
拒绝它n
,甚至可以手动编辑它。以下是选项:
y - apply this hunk to index and worktree
n - do not apply this hunk to index and worktree
q - quit; do not apply this hunk or any of the remaining ones
a - apply this hunk and all later hunks in the file
d - do not apply this hunk or any of the later hunks in the file
g - select a hunk to go to
/ - search for a hunk matching the given regex
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
K - leave this hunk undecided, see previous hunk
s - split the current hunk into smaller hunks
e - manually edit the current hunk
? - print help
我想进去手动编辑一个大块,因为我不想完全按照它的姿势接受或拒绝合并。所以我选择e
并获得了一个要编辑的文件。当我注意到底部甚至有关于如何正确编辑大块的说明时,我很高兴。s
您甚至可以使用上述选项将大块分成较小的块。
如果你想要的是手动合并,我会推荐这个过程,你仍然尽可能地利用自动过程。不同之处在于您可以监督每个合并“大块”并随意编辑它们。我希望这对未来的读者有所帮助。
在此过程之后,您可能希望运行git checkout branchToMergeTo && git merge branchToMergeFrom
以将历史正式合并branchToMergeFrom
到branchToMergeTo
.
请注意,如果您坚持手动合并(可能针对某一类文件),您仍然可以定义合并驱动程序。您在“ Git - 如何强制合并冲突和手动合并所选文件
”
中有一个具体示例。
这样,您的合并驱动程序脚本可以调用您想要的任何合并工具。
我选择我们的策略(它也作为 TortoiseGit 中的一个选项存在),在进行手动差异之后,您已经手动引入了您想要的更改。
来自: https ://git-scm.com/docs/merge-strategies
合并机制(git merge 和 git pull 命令)允许使用 -s 选项选择后端“合并策略”。一些策略也可以采用自己的选项,可以通过将 -X 参数传递给 git merge 和/或 git pull 来传递。
我们的
这解决了任意数量的头,但合并的结果树始终是当前分支头的树,有效地忽略了所有其他分支的所有更改。它旨在用于取代分支的旧开发历史。请注意,这与“递归”合并策略的 -Xours 选项不同。
然而,Bitbucket 稍后看到的内容对我来说是个谜,它将提交识别为合并但未能实际合并分支(不解决拉取请求) - 可能 Bitbucket 大师可以帮助解决这个问题,我什至不能给你任何日志/错误消息,因为我没有那种可见性 - git/TortoiseGit 一点也不抱怨。