1

私はリポジトリからプルしたいのですが、私のリポジトリと衝突するそのリポジトリからの変更セットがより良い選択肢であると信じています。

マージの競合に対処する必要がなく、プル元のリポジトリが常に戦いに勝つように、プルを自動化するにはどうすればよいですか?

コマンド ライン オプションをgit pull --squash見てみると、それが探しているものなのか、それとも何らかのマージ戦略を適用する必要があるのか​​、正確にはわかりません。何に渡すのかわかりません

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

また

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

それが実際に私が使用すべきフラグの1つである場合。

4

1 に答える 1

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競合するコミットを 1 つずつ調べます。

于 2014-01-24T00:25:36.063 に答える