반응형
git의 병합 전략은 무엇입니까?
중복 가능성 :
언제 다른 git 병합 전략을 사용합니까?
git이 내가 작업중인 파일을 병합하면 다음과 같이 표시됩니다.
Merge made by the 'recursive' strategy
재귀 전략은 정확히 무엇입니까? 어떤 다른 전략이 있습니까 (있는 경우)? 그리고 하나를 다른 것보다 사용하면 어떤 이점이 있습니까? 전략마다 다른 성과가 있습니까? 아니면 두 가지 다른 전략이 서로 다른 병합 결과를 가져올 수 있습니까?
에서 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.
참조 URL : https://stackoverflow.com/questions/14243397/what-are-gits-merge-strategies
반응형
'Nice programing' 카테고리의 다른 글
각도 및 마이크로 프런트 엔드 (0) | 2021.01.08 |
---|---|
Android에서 서식있는 텍스트 편집기를 구현하고 계십니까? (0) | 2021.01.08 |
Node.js는 Blob을 만들 수 없습니까? (0) | 2021.01.08 |
iOS 9 용 Xcode 7에서 XPC 연결이 중단됨 (0) | 2021.01.08 |
LLVM 프로필 오류 :“default.profraw”파일 쓰기 실패 : 권한이 거부되었습니다. (0) | 2021.01.08 |