다른 git 병합 전략 사용 시기

 

질문 : 다른 git 병합 전략을 언제 사용합니까?

---

git-merge의 man 페이지에서 사용할 수있는 병합 전략이 많이 있습니다.

• resolve -3 방향 병합 알고리즘을 사용하여 두 개의 헤드 (즉, 현재 분기와 가져온 다른 분기) 만 해결할 수 있습니다. 교차 병합 모호성을주의 깊게 감지하려고 시도하며 일반적으로 안전하고 빠른 것으로 간주됩니다.
• 재귀 -3 방향 병합 알고리즘을 사용하여 두 개의 머리 만 해결할 수 있습니다. 3 방향 병합에 사용할 수있는 공통 조상이 둘 이상인 경우 공통 조상의 병합 트리를 생성하고이를 3 방향 병합에 대한 참조 트리로 사용합니다. 이는 Linux 2.6 커널 개발 기록에서 가져온 실제 병합 커밋에 대해 수행 된 테스트에서 잘못된 병합을 일으키지 않고 병합 충돌을 줄인 것으로보고되었습니다. 또한 이것은 이름 변경과 관련된 병합을 감지하고 처리 할 수 있습니다. 이것은 하나의 분기를 가져 오거나 병합 할 때 기본 병합 전략입니다.
• octopus- 두 개 이상의 경우를 해결하지만 수동 해결이 필요한 복잡한 병합은 거부합니다. 주로 토픽 브랜치 헤드를 함께 묶는 데 사용됩니다. 이는 둘 이상의 분기를 가져 오거나 병합 할 때 기본 병합 전략입니다.
• ours- 이것은 수에 관계없이 헤드를 해결하지만 병합의 결과는 항상 현재 분기 헤드입니다. 사이드 브랜치의 오래된 개발 역사를 대체하는 데 사용됩니다.
• 하위 트리 -수정 된 재귀 전략입니다. 트리 A와 B를 병합 할 때 B가 A의 하위 트리에 해당하면 B는 먼저 동일한 수준에서 트리를 읽는 대신 A의 트리 구조와 일치하도록 조정됩니다. 이 조정은 공통 조상 트리에도 적용됩니다.

 

 

기본값과 다른 것을 언제 지정해야합니까? 각 시나리오에 가장 적합한 시나리오는 무엇입니까?

답변

---

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

재귀는 비 빨리 감기 병합의 기본값입니다. 우리는 모두 그것에 익숙합니다.

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

문어 브랜치는 깔끔하게 할 수있는 한 하나의 커밋에서 여러 개의 헤드를 병합합니다.

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

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

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

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

우리 == 나는 다른 머리를 당기고 싶지만 머리가 도입하는 모든 변화를 버리십시오.

이것은 분기의 영향없이 분기의 역사를 유지합니다.

(읽기 : 해당 분기 간의 변경 사항도 확인하지 않습니다. 분기는 병합되고 파일에 아무 작업도 수행되지 않습니다. 다른 분기에서 병합하고 싶을 때마다 "우리 파일 버전 또는 version "을 사용할 수 있습니다. git merge -X ours )

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

출처 : https://stackoverflow.com/questions/366860/when-would-you-use-the-different-git-merge-strategies