通过愚蠢，大文件的唯一版本是尝试合并，即它包含许多行，如
<<<<<<< HEAD double[] p1 = ...
double[] p2 = ...
======= double[] p1 = ...
double[] p2 = ...
>>>>>>> origin/foo
我如何摆脱这些，而不必编辑每一个，总是选择HEAD？
合并和一些愚蠢的命令让我没有看到我的原始HEAD，但幸运的是git reflog帮助我在合并之前找到了位置。
答案 0 :(得分：1)
如果您想总是选择HEAD，那么您正在寻找名为merge strategy的{{1}}。
执行ours
在合并时引用git帮助：
合并战略 合并机制（git-merge和git-pull命令）允许使用-s选项选择后端合并策略。一些 策略也可以采用自己的选项，可以通过给git-merge和/或git-pull提供-X参数来传递。
git merge -s ours <branch-to-merge>这些是列出的一些策略。
使用 recursive
This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used
for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge.
This has been reported to result in fewer merge conflicts without causing mis-merges by tests done on actual merge commits
taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames. This is
the default merge strategy when pulling or merging one branch.
The recursive strategy can take the following options:
ours
This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree
that do not conflict with our side are reflected to the merge result.
This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at
all. It discards everything the other tree did, declaring our history contains all that happened in it.
theirs
This is opposite of ours.
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.
查找更多内容。
答案 1 :(得分：0)
通过将-X ignore-space-change传递给命令行，您可以在合并时忽略空间更改，这也适用于git rebase。