Git 병합 전략 옵션 및 예시
작업이 완료되고 테스트를 거쳐 메인 개발 라인에 다시 병합될 준비가 되면 팀에서는 정책을 선택해야 합니다. 여러분의 병합 전략 옵션은 무엇입니까? 이 글에서는 가능성을 살펴본 다음 Atlassian에서는 어떻게 운영하는지에 대해 몇 가지 의견을 제시할 것입니다. 마지막에는 팀에 가장 적합한 것이 무엇인지 결정할 수 있는 도구를 갖게 되기를 바랍니다.
Git 병합 전략
병합은 두 브랜치를 결합할 때 발생합니다. Git은 두 개(또는 그 이상)의 커밋 포인터를 가져와서 그 사이의 공통된 기준 커밋을 찾으려고 시도합니다. Git에는 기준 커밋을 찾는 여러 방법이 있으며 이러한 방법을 "병합 전략"이라고 합니다. Git은 공통된 기준 커밋을 찾으면 지정된 병합 커밋의 변경 사항을 결합하는 새 "병합 커밋"을 만듭니다. 엄밀히 말하자면 병합 커밋은 두 개의 상위 커밋이 있는 일반 커밋입니다.
명시적으로 지정하지 않는 한 git merge는 자동으로 병합 전략을 선택합니다. git merge 및 git pull 명령에 -s(전략) 옵션을 전달할 수 있습니다. -s 옵션에 원하는 병합 전략의 이름을 추가할 수 있습니다. 명시적으로 지정하지 않으면 Git은 제공된 브랜치를 기반으로 가장 적합한 병합 전략을 선택합니다. 사용 가능한 병합 전략은 다음과 같습니다.
관련 자료
고급 Git 로그
솔루션 보기
Bitbucket Cloud에서 Git에 대해 알아보기
Recursive
git merge -s recursive branch1 branch2두 개의 헤드에서 작동하는 전략으로, recursive는 브랜치 하나를 풀하거나 병합할 때의 기본 병합 전략입니다. 또한 이름 변경과 관련된 병합은 감지하고 처리할 수 있지만 현재는 감지된 복사본을 사용할 수 없습니다. 브랜치 하나를 풀하거나 병합할 때의 기본 병합 전략입니다.
해결
git merge -s resolve branch1 branch2이 전략은 3방향 병합 알고리즘을 사용하여 두 개의 헤드만 해결할 수 있습니다. 교차 병합의 모호성을 신중하게 감지하려고 하며 대체로 안전하고 빠른 전략으로 간주됩니다.
Octopus
git merge -s octopus branch1 branch2 branch3 branchN세 개 이상의 헤드에 대한 기본 병합 전략입니다. 두 개 이상의 브랜치가 전달되면 octopus는 자동으로 이루어집니다. 병합에 수동 해결이 필요한 충돌이 생기면 octopus는 병합 시도를 거부합니다. 주로 비슷한 기능 브랜치 헤드를 함께 묶는 데 사용됩니다.
Ours
git merge -s ours branch1 branch2 branchNours 전략은 N개의 여러 브랜치에서 작동합니다. 출력 병합 결과는 항상 현재 브랜치 HEAD의 결과에 해당합니다. "ours"라는 용어는 다른 모든 브랜치의 변경 사항을 사실상 무시한다는 기본 설정을 의미합니다. 비슷한 기능 브랜치의 기록을 결합하는 데 사용됩니다.
Subtree
git merge -s subtree branchA branchBrecursive 전략의 연장선입니다. A와 B를 병합할 때 B가 A의 하위 트리이면 B가 먼저 A의 트리 구조를 반영하도록 업데이트됩니다. 이 업데이트는 A와 B가 공유하는 공통 상위 트리에 대해서도 이루어집니다.
Git 병합 전략의 유형
명시적 병합
명시적 병합은 기본 병합 유형입니다. '명시적'인 이유는 새 병합 커밋을 만들기 때문입니다. 그러면 커밋 기록이 변경되고 병합이 실행된 위치가 명시적으로 표시됩니다. 병합 커밋 콘텐츠도 어떤 커밋이 병합 커밋의 상위 항목이었는지 보여준다는 점에서 명시적입니다. 일부 팀에서는 병합 커밋이 프로젝트 기록에 "불필요한 부분"을 더한다는 이유로 명시적 병합을 사용하지 않습니다.
rebase 또는 빨리 감기 병합을 통한 암시적 병합
일반적으로 명시적 병합이 없는 병합 시 스쿼시
Recursive Git 병합 전략 옵션
위에서 소개한 'recursive' 전략에는 추가 작업 옵션의 고유한 하위 집합이 있습니다.
oursours 병합 전략과 혼동하지 않아야 합니다. 이 옵션에서는 'ours' 버전을 선호하여 충돌을 깔끔하게 자동으로 해결합니다. 'theirs' 측의 변경 사항은 충돌하지 않는 경우 자동으로 통합됩니다.
theirs'ours' 전략과는 반대인 "theirs" 옵션은 충돌 해결에서 외부의 병합 트리를 선호합니다.
patience이 옵션은 중요하지 않은 일치하는 줄이 잘못 병합되는 것을 방지하는 데 시간을 더욱 많이 들입니다. 병합할 브랜치가 극도로 분기되었을 때 사용하는 것이 가장 좋습니다.
diff-algorithimignore-*
ignore-space-change
ignore-all-space
ignore-space-at-eol
ignore-cr-at-eol공백 문자를 대상으로 하는 옵션의 집합입니다. 전달된 옵션의 하위 집합과 일치하는 줄은 모두 무시됩니다.
renormalize이 옵션은 3방향 병합 문제를 해결하면서 git 트리 전체에 대한 체크아웃과 체크인을 실행합니다. 이 옵션은 checkin/checkout 상태가 다른 브랜치를 병합하는 데 사용하기 위한 것입니다.
no-normalize재정규화 옵션을 사용 중지합니다. 이는 merge.renormalize 구성 변수를 재정의합니다.
no-renames이 옵션은 병합하는 동안 이름이 변경된 파일을 무시합니다.
find-renames=n기본 동작입니다. recursive 병합에서는 파일 이름 변경이 적용됩니다. n 매개 변수는 이름 변경 유사성 임계값을 전달하는 데 사용할 수 있습니다. 기본 n 값은 100%입니다.
subtree이 옵션은 `하위 트리` 전략에서 차용했습니다. 전략이 두 트리에서 작동하고 공유 상위 항목과 일치시키는 방법을 수정하는 경우 이 옵션이 대신 트리의 경로 메타데이터에서 작동하여 일치시키도록 만들어졌습니다.
Atlassian의 Git 병합 정책
Atlassian에서는 명시적 병합을 매우 선호합니다. 그 이유는 아주 간단합니다. 명시적 병합은 병합되는 기능에 대한 뛰어난 추적성과 컨텍스트를 제공하기 때문입니다. 검토를 위해 기능 브랜치를 공유하기 전에 로컬 기록 정리 rebase를 수행하는 것을 적극 권장하지만, 이로 인해 정책이 변경되는 것은 아니며 오히려 정책을 보완해 줍니다.
이 문서 공유
다음 토픽
여러분께 도움을 드릴 자료를 추천합니다.
이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.
Bitbucket 블로그
DevOps 학습 경로
