왜 Subversion에서보다 DVCS에서 병합이 더 좋은지에 대한 주장은 주로 Subversion에서 분기 및 병합이 어떻게 작동했는지에 근거한 것입니다. 1.5.0 이전의 Subversion 은 브랜치가 병합 된시기에 대한 정보를 저장하지 않았으므로 병합을 원할 때 병합해야하는 개정 범위를 지정해야했습니다.
그렇다면 Subversion 병합은 왜 빨랐 습니까?
이 예를 깊이 생각해보십시오.
1 2 4 6 8
trunk o-->o-->o---->o---->o
\
\ 3 5 7
b1 +->o---->o---->o
b1의 변경 사항을 트렁크 에 병합 하려면 트렁크가 체크 아웃 된 폴더에 서있는 동안 다음 명령을 실행합니다.
svn merge -r 2:7 {link to branch b1}
… 변경 사항을 b1로컬 작업 디렉토리 에 병합하려고 시도합니다 . 그런 다음 충돌을 해결하고 결과를 테스트 한 후 변경 사항을 커밋합니다. 수정 트리를 커밋하면 다음과 같습니다.
1 2 4 6 8 9
trunk o-->o-->o---->o---->o-->o "the merge commit is at r9"
\
\ 3 5 7
b1 +->o---->o---->o
그러나 버전 트리가 커질 때 subversion에 병합 된시기와 대상에 대한 메타 데이터가 없기 때문에 버전 범위를 지정하는이 방법은 빠르게 사라집니다. 나중에 일어날 일에 대해 숙고하십시오.
12 14
trunk …-->o-------->o
"Okay, so when did we merge last time?"
13 15
b1 …----->o-------->o
이것은 Subversion이 가지고있는 리포지토리 디자인의 문제입니다. 브랜치를 만들려면 트렁크의 복사본을 보관할 리포지토리에 새 가상 디렉터리 를 만들어야 하지만 언제 어디서 무엇에 관한 정보도 저장하지 않습니다. 일이 다시 합쳐졌습니다. 때로는 불 합병 한 병합 충돌이 발생할 수 있습니다. 더 나쁜 것은 Subversion이 기본적으로 양방향 병합을 사용했기 때문에 두 분기 헤드가 공통 조상과 비교되지 않은 경우 자동 병합에 약간의 제한이 있습니다.
이 Subversion을 완화하기 위해 이제 분기 및 병합을위한 메타 데이터가 저장됩니다. 그것은 모든 문제를 올바르게 해결할 것입니까?
그리고, 그런데, Subversion은 여전히 엉망입니다 ...
Subversion과 같은 중앙 집중식 시스템에서 가상 디렉터리는 빨라집니다. 왜? 모든 사람이 볼 수있는 액세스 권한이 있기 때문에 ... 쓰레기 실험적인 사람도 있습니다. 실험하고 싶지만 모든 사람과 이모 실험을보고 싶지 않은 경우 분기가 좋습니다 . 이것은 심각한인지 소음입니다. 더 많은 가지를 추가할수록 더 많은 쓰레기를 볼 수 있습니다.
저장소에 공용 지점이 많을수록 다른 지점을 모두 추적하기가 더 어려워집니다. 따라서 지점이 아직 개발 중이거나 실제로 죽은 경우 중앙 집중식 버전 제어 시스템에서 말하기 어려운 질문이 있습니다.
대부분 내가 본 것으로부터 조직은 기본적으로 하나의 큰 지점을 사용하도록 기본 설정합니다. 테스트 및 릴리스 버전을 추적하기가 어려우며 분기에서 오는 좋은 점이 있기 때문에 부끄러운 일입니다.
그렇다면 Git, Mercurial 및 Bazaar와 같은 DVCS가 분기 및 병합에서 Subversion보다 나은 이유는 무엇입니까?
이유는 매우 간단한 이유가 있습니다. 분기는 일류 개념 입니다. DVCS 에는 가상 디렉터리 가 의도적으로 설계 되어 있지 않으며 , 저장소는 저장소 동기화 (즉, push 및 pull ) 와 함께 간단하게 작동하기 위해 필요한 DVCS의 하드 개체입니다 .
DVCS로 작업 할 때 가장 먼저해야 할 일은 리포지토리 (git 's clone, hg 's clone및 bzr 's branch) 를 복제하는 것 입니다. 복제는 개념적으로 버전 관리에서 분기를 만드는 것과 같습니다. 일부는 이것을 분기 또는 분기 라고 부릅니다 (후자는 종종 같은 위치에있는 분기를 가리키는 데 사용 되기는하지만). 모든 사용자는 자체 저장소를 실행하므로 사용자 별 분기가 진행됩니다.
버전 구조는 트리 가 아니라 그래프 입니다. 보다 구체적으로, 유향 비순환 그래프 (DAG, 사이클이없는 그래프를 의미). 각 커밋에 하나 이상의 부모 참조 (커밋이 기반으로 한 것)가있는 것을 제외하고는 DAG의 세부 사항을 다루지 않아도됩니다. 따라서 다음 그래프는 이로 인해 개정판 사이의 화살표를 반대로 표시합니다.
병합의 매우 간단한 예는 다음과 같습니다. 호출 된 중앙 저장소 origin와 사용자 Alice가 저장소를 시스템에 복제 한다고 상상해보십시오 .
a… b… c…
origin o<---o<---o
^master
|
| clone
v
a… b… c…
alice o<---o<---o
^master
^origin/master
복제하는 동안 발생하는 모든 수정 사항은 고유 한 식별 가능한 해시 ID로 확인 된 그대로 수정 사항이 Alice에 복사되고 원본 분기의 위치를 표시합니다.
그런 다음 Alice는 리포지토리에서 작업하면서 자체 리포지토리에 커밋하고 변경 사항을 적용하기로 결정합니다.
a… b… c…
origin o<---o<---o
^ master
"what'll happen after a push?"
a… b… c… d… e…
alice o<---o<---o<---o<---o
^master
^origin/master
해결책은 다소 간단합니다. origin리포지토리에서 수행해야 할 유일한 것은 모든 새 개정을 가져 와서 분기를 최신 개정으로 이동하는 것입니다 (git은 "fast-forward"라고 부릅니다).
a… b… c… d… e…
origin o<---o<---o<---o<---o
^ master
a… b… c… d… e…
alice o<---o<---o<---o<---o
^master
^origin/master
위에서 설명한 유스 케이스 는 아무것도 병합 할 필요조차 없습니다 . 따라서 3 방향 병합 알고리즘은 모든 버전 제어 시스템에서 거의 동일하므로 문제는 실제로 알고리즘 병합과 관련이 없습니다. 문제는 무엇보다 구조에 관한 것 입니다.
그렇다면 실제 병합 이있는 예를 보 시겠습니까?
위의 예는 매우 간단한 사용 사례이므로 더 일반적인 방법이지만 훨씬 더 많이 꼬아 놓을 수 있습니다. origin세 가지 개정으로 시작한 것을 기억 하십니까? 글쎄, 그들을 한 사람은 그를 Bob 이라고 부를 수 있으며, 스스로 작업하고 자신의 저장소에 커밋했습니다.
a… b… c… f…
bob o<---o<---o<---o
^ master
^ origin/master
"can Bob push his changes?"
a… b… c… d… e…
origin o<---o<---o<---o<---o
^ master
이제 Bob은 변경 사항을 origin저장소로 직접 푸시 할 수 없습니다 . 시스템이이를 감지하는 방법은 Bob의 수정본이에서 수정 origin되지 않는지 확인하는 것입니다 (이 경우에는 그렇지 않음). 밀어 붙이려 고 시도하면 시스템은 " 어 .. 밥이 그렇게 할 수 없을 까봐 두렵습니다 ."
따라서 Bob은 변경 사항을 가져 pull와서 변경해야합니다 (git 's ; 또는 hg 's pull및 merge; 또는 bzr 's merge). 이것은 2 단계 프로세스입니다. 먼저 Bob은 새 개정을 가져와야합니다. 그러면 개정판이 origin저장소 에서있는 그대로 복사됩니다 . 그래프가 갈라지는 것을 볼 수 있습니다.
v master
a… b… c… f…
bob o<---o<---o<---o
^
| d… e…
+----o<---o
^ origin/master
a… b… c… d… e…
origin o<---o<---o<---o<---o
^ master
풀 프로세스의 두 번째 단계는 분기 팁을 병합하고 결과를 커밋하는 것입니다.
v master
a… b… c… f… 1…
bob o<---o<---o<---o<-------o
^ |
| d… e… |
+----o<---o<--+
^ origin/master
희망 병합은 (당신이 그들을 예상되는 경우 수동으로 자식의 두 단계를 할 수있는 충돌로 실행되지 않습니다 fetch및 merge). 나중에 수행해야 할 작업은 해당 변경 사항을 다시 (으)로 푸시 origin하는 것입니다. 병합 커밋은 origin리포지토리 에서 최신 버전의 직접적인 후손이므로 빨리 병합됩니다 .
v origin/master
v master
a… b… c… f… 1…
bob o<---o<---o<---o<-------o
^ |
| d… e… |
+----o<---o<--+
v master
a… b… c… f… 1…
origin o<---o<---o<---o<-------o
^ |
| d… e… |
+----o<---o<--+
라는 자식과 HG에 병합하는 또 다른 옵션이 있습니다 REBASE 최신 변경 후 밥의 변화를 이동 which'll는. 이 답변이 더 이상 장황하게되기를 원하지 않기 때문에 대신 git , mercurial 또는 bazaar 문서 를 읽도록하겠습니다 .
독자를위한 연습으로 관련된 다른 사용자와 어떻게 작동하는지 알아보십시오. Bob의 경우 위의 예제와 유사하게 수행됩니다. 모든 개정 / 커밋은 고유하게 식별 가능하기 때문에 리포지토리 간 병합이 생각보다 쉽습니다.
각 개발자 사이에 패치를 보내는 문제도 있습니다. Subversion의 고유 한 문제는 git, hg 및 bzr에서 고유하게 식별 가능한 수정으로 완화되었습니다. 누군가 자신의 변경 사항을 병합 (예 : 병합 커밋)하고 팀의 다른 모든 사람이 중앙 리포지토리로 푸시하거나 패치를 보내서 소비 할 수 있도록 보내면 병합에 대해 걱정할 필요가 없습니다. . Martin Fowler는 이러한 방식으로 무차별 통합을 수행 합니다.
Subversion과 구조가 다르기 때문에 대신 DAG를 사용하면 시스템뿐만 아니라 사용자도보다 쉽게 분기 및 병합을 수행 할 수 있습니다.