언제 다른 git merge 전략을 사용 하시겠습니까?

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

• resolve -3-way merge 알고리즘을 사용하여 두 개의 헤드 (즉, 현재 분기 및 가져온 다른 분기) 만 해결할 수 있습니다. 십자 병합 모호성을 신중하게 감지하려고 시도하며 일반적으로 안전하고 빠른 것으로 간주됩니다.

• 재귀 -3 방향 병합 알고리즘을 사용하여 두 개의 헤드 만 분석 할 수 있습니다. 3 방향 병합에 사용할 수있는 공통 조상이 둘 이상있는 경우 공통 조상의 병합 된 트리를 생성하고이를 3 방향 병합의 참조 트리로 사용합니다. 이는 Linux 2.6 커널 개발 히스토리에서 가져온 실제 병합 커밋에서 수행 된 테스트로 인해 병합 오류가 발생하지 않으면 서 병합 충돌을 줄이는 것으로보고되었습니다. 또한 이름 변경과 관련된 병합을 감지하고 처리 할 수 ​​있습니다. 하나의 브랜치를 가져 오거나 병합 할 때의 기본 병합 전략입니다.

• 문어 -두 개 이상의 사례를 해결하지만 수동 해결이 필요한 복잡한 병합을 거부합니다. 주로 토픽 브랜치 헤드를 묶는 데 사용됩니다. 둘 이상의 분기를 가져 오거나 병합 할 때의 기본 병합 전략입니다.

• ours- 헤드 수를 결정하지만 병합 결과는 항상 현재 분기 헤드입니다. 사이드 브랜치의 오래된 개발 히스토리를 대체하는 데 사용됩니다.

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

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

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

재귀

재귀는 빨리 감기가 아닌 병합의 기본값입니다. 우리는 모두 그 점에 익숙합니다.

문어

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

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

예를 들어, 마스터가있는 프로젝트와 병합 할 세 가지 분기가 있다고 가정합니다 (a, b 및 c라고 함).

일련의 재귀 병합은 다음과 같습니다 (재귀를 강제하지 않았으므로 첫 번째 병합은 빨리 진행되었습니다).

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

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

우리 것

우리의 == 다른 머리를 잡아 당기고 싶지만 머리가 도입 한 모든 변화를 버립니다.

이렇게하면 분기의 영향없이 분기의 기록이 유지됩니다.

(읽기 : 해당 브랜치 간의 변경 사항을 보지도 않았습니다. 브랜치가 병합되고 파일에 아무런 작업도 수행되지 않습니다. 다른 브랜치에서 병합하려면 매번 "파일 버전 또는 버전 "을 사용할 수 있음 git merge -X ours)

서브 트리

하위 트리는 다른 프로젝트에서 현재 프로젝트의 하위 디렉토리로 병합 할 때 유용합니다. 하위 모듈로 포함하지 않으려는 라이브러리가있을 때 유용합니다.