如何运行'git pull'以使其始终有效,并且合并冲突会破坏我的更改?

时间:2014-01-24 00:23:22

标签: git git-merge git-pull git-workflow

我想从存储库中取出,我相信从该存储库发生的任何与我的冲突的更改集是更好的选择。

如何自动化拉动,这样我就不必处理任何合并冲突,而且我从中拉出的存储库总能赢得这场战斗?

查看命令行选项,我不确定git pull --squash是否是我正在寻找的,或者我是否必须应用某种合并策略。我无法弄清楚我会传递给

-s <strategy>
--strategy=<strategy>

-X <option>
--strategy-option=<option>

如果那确实是我应该使用的标志之一。

1 个答案:

答案 0 :(得分:5)

您正在寻找带有recursive选项的策略theirs

git pull -s recursive -X theirs

来自git-pull手册页:

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. For a
    binary file, the entire contents are taken from our side.

    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 the opposite of ours.

然而,这确实不是一个好主意。即使您相信上游的更改是正确的,您如何知道它们可以处理不会导致冲突的更改?

我个人更喜欢git pull --rebase而不是直接git pull,并逐个检查每个冲突的提交。