언제 다른 git merge 전략을 사용합니까?

Question

git-merge의 매뉴얼 페이지에는 사용할 수 있는 여러 병합 전략이 있습니다.

• 해결하다 - 이것은 두 개의 헤드 만 해결할 수 있습니다 (즉현재 분기와 가져온 다른 분기) 3방향 병합 알고리즘을 사용합니다.교차 병합 모호성을 주의 깊게 감지하려고 시도하며 일반적으로 안전하고 빠른 것으로 간주됩니다.

• 재귀적 - 이것은 3 방향 병합 알고리즘을 사용하여 두 개의 헤드 만 해결할 수 있습니다.3방향 병합에 사용할 수 있는 공통 조상이 두 개 이상인 경우 공통 조상의 병합 트리를 생성하고 이를 3방향 병합을 위한 참조 트리로 사용합니다.이는 Linux 2.6 커널 개발 기록에서 가져온 실제 병합 커밋에 대한 테스트를 통해 잘못된 병합을 유발하지 않고 병합 충돌을 줄이는 것으로 보고되었습니다.또한 이는 이름 바꾸기와 관련된 병합을 감지하고 처리할 수 있습니다.이는 하나의 분기를 가져오거나 병합할 때의 기본 병합 전략입니다.

• 문어 - 이것은 두 개 이상의 헤드 케이스를 해결하지만 수동 해상도가 필요한 복잡한 병합을 거부합니다.이는 주로 주제 분기 헤드를 함께 묶는 데 사용됩니다.이는 둘 이상의 분기를 가져오거나 병합할 때의 기본 병합 전략입니다.

• 우리 것 - 이것은 몇 가지 헤드를 해결하지만 병합의 결과는 항상 현재 지점 헤드입니다.이는 사이드 브랜치의 오래된 개발 기록을 대체하는 데 사용됩니다.

• 하위 트리 - 이것은 수정 된 재귀 전략입니다.트리 A와 B를 병합할 때 B가 A의 하위 트리에 해당하면 동일한 수준의 트리를 읽는 대신 B가 먼저 A의 트리 구조와 일치하도록 조정됩니다.이 조정은 공통 조상 트리에도 적용됩니다.

기본값과 다른 것을 언제 지정해야 합니까?각각 어떤 시나리오에 가장 적합합니까?

Answer 1

나는 해결에 익숙하지 않지만 다른 것을 사용했습니다.

재귀적

재귀는 빨리 감기가 아닌 병합의 기본값입니다.우리 모두는 그것에 대해 잘 알고 있습니다.

문어

병합해야 할 나무가 여러 개 있을 때 문어를 사용했습니다.많은 지점이 독립적으로 개발되었으며 모두 단일 헤드로 통합될 준비가 되어 있는 대규모 프로젝트에서 이를 볼 수 있습니다.

Octopus 브랜치는 깨끗하게 수행할 수 있는 한 하나의 커밋으로 여러 헤드를 병합합니다.

설명을 위해 마스터가 있고 병합할 세 개의 분기(a, b, c라고 함)가 있는 프로젝트가 있다고 가정해 보겠습니다.

일련의 재귀 병합은 다음과 같습니다(재귀를 강제하지 않았기 때문에 첫 번째 병합은 빨리 감기였습니다).

그러나 단일 문어 병합은 다음과 같습니다.

commit ae632e99ba0ccd0e9e06d09e8647659220d043b9
Merge: f51262e... c9ce629... aa0f25d...

우리 것

우리 것 == 다른 헤드를 끌어오고 싶지만 헤드가 도입하는 변경 사항은 모두 버리십시오.

이는 분기의 영향 없이 분기의 기록을 유지합니다.

(읽다:해당 지점 간의 변경 사항도 살펴보지 않았습니다.브랜치는 병합만 되고 파일에는 아무 작업도 수행되지 않습니다.다른 브랜치에 병합하고 싶을 때 "우리 파일 버전 또는 해당 버전"이라는 질문이 있을 때마다 다음을 사용할 수 있습니다. git merge -X ours)

하위 트리

하위 트리는 다른 프로젝트를 현재 프로젝트의 하위 디렉터리에 병합하려는 경우 유용합니다.하위 모듈로 포함하고 싶지 않은 라이브러리가 있을 때 유용합니다.

Answer 2

실제로 선택하고 싶은 유일한 두 가지 전략은 다음과 같습니다. 우리 것 브랜치에서 가져온 변경 사항을 취소하고 브랜치를 기록에 유지하려는 경우 하위 트리 독립 프로젝트를 슈퍼 프로젝트의 하위 디렉터리(예: 'git' 저장소의 'git-gui')에 병합하는 경우.

문어 merge는 두 개 이상의 브랜치를 병합할 때 자동으로 사용됩니다. 해결하다 주로 역사적인 이유로 이곳에 왔습니다. 재귀적 병합 전략 코너 케이스.

Answer 3

"해결" 대 "재귀" 병합 전략

Recursive는 현재의 기본 2헤드 전략이지만 몇 가지 검색 끝에 마침내 "해결" 병합 전략에 대한 정보를 찾았습니다.

오라일리 책에서 발췌 Git을 사용한 버전 관리 (아마존) (의역):

원래 "해결"은 Git 병합의 기본 전략이었습니다.

가능한 병합 기준이 두 개 이상인 교차 병합 상황에서 해결 전략은 다음과 같이 작동합니다.가능한 병합 기반 중 하나를 선택하고 최선을 다하십시오.실제로 이것은 들리는 것만큼 나쁘지는 않습니다.사용자가 코드의 다른 부분을 작업하고 있는 경우가 종종 있습니다.이 경우 Git은 이미 적용된 일부 변경 사항을 다시 병합하고 있음을 감지하고 충돌을 피하기 위해 중복된 변경 사항을 건너뜁니다.또는 충돌을 일으키는 사소한 변경인 경우 적어도 개발자가 충돌을 쉽게 처리할 수 있어야 합니다.

기본 재귀 전략으로 실패한 "해결"을 사용하여 트리를 성공적으로 병합했습니다.나는 점점 fatal: git write-tree failed to write a tree 오류, 그리고 덕분에 이 블로그 게시물 (거울) "-s 해결"을 시도했는데 효과가 있었습니다.아직도 왜 그런지는 정확히 모르겠습니다...하지만 두 트리 모두에 중복된 변경 사항이 있어서 "건너뛴" 문제를 올바르게 해결했기 때문이라고 생각합니다.