Jakie są strategie scalania git?

Question

Powiel możliwe:
When would you use the different git merge strategies?

Kiedy git łączy pliki pracuję nad widzę:

Merge made by the 'recursive' strategy 

Czym dokładnie jest strategia rekurencyjne? Jakie są inne strategie (jeśli istnieją)? I jaka byłaby korzyść z używania jednego z drugim? Czy różne strategie mają różne wyniki? A może dwie różne strategie powodują różne wyniki scalania?

Answer 1

Od git help merge:

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<option> arguments to git-merge and/or git-pull. 

    resolve 
     This can only resolve two heads (i.e. the current branch and 
     another branch you pulled from) using a 3-way merge algorithm. It 
     tries to carefully detect criss-cross merge ambiguities and is 
     considered generally safe and fast. 

    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. 

     subtree[=path] 
      This option is a more advanced form of subtree strategy, where 
      the strategy makes a guess on how two trees must be shifted to 
      match with each other when merging. Instead, the specified path 
      is prefixed (or stripped from the beginning) to make the shape 
      of two trees to match. 

    octopus 
     This resolves cases with more than two heads, but refuses to do a 
     complex merge that needs manual resolution. It is primarily meant 
     to be used for bundling topic branch heads together. This is the 
     default merge strategy when pulling or merging more than one 
     branch. 

    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. 

    subtree 
     This is a modified recursive strategy. When merging trees A and B, 
     if B corresponds to a subtree of A, B is first adjusted to match 
     the tree structure of A, instead of reading the trees at the same 
     level. This adjustment is also done to the common ancestor tree.