rebase(및 cherry-pick) 모두 merge장단점이 있습니다. 나는 merge여기서 주장 하지만 둘 다 이해할 가치가 있습니다. ( 여기서 선호되는 사례를 열거 하는 다른 논쟁의 여지가 많은 답변을 찾으십시오 rebase.)
merge선호되는 cherry-pick과 rebase몇 가지 이유.
- 견고성 . 커밋의 SHA1 식별자는 커밋뿐만 아니라 그 앞에 오는 다른 모든 커밋 과 관련하여 식별 합니다. 이를 통해 지정된 SHA1의 리포지토리 상태가 모든 클론에서 동일하다는 것을 보장 할 수 있습니다. 이론상 누군가가 같은 변화처럼 보이는 것을했지만 실제로 저장소를 손상 시키거나 납치 할 가능성은 없습니다. 개별 변경 사항에서 체리 픽을 선택할 수 있으며 변경 사항은 동일하지만 보장 할 수는 없습니다. (사소한 보조 문제로, 새로운 체리 피킹 커밋은 다른 누군가가 동일한 커밋에서 체리 피킹을 다시 수행하면 작업 공간이 동일하더라도 역사에 모두 표시되므로 추가 공간을 차지합니다.)
- 사용 편의성 . 사람들은
merge작업 흐름을 상당히 쉽게 이해하는 경향이 있습니다. rebase더 진보 된 것으로 간주되는 경향이 있습니다. 두 가지를 모두 이해하는 것이 가장 좋지만 버전 관리 전문가가되고 싶지 않은 사람들 (내 경험상 자신이하는 일에 능숙하지만 여분의 시간을 보내고 싶지 않은 많은 동료들이 포함되어 있음) 시간이 합병.
심지어 병합 무거운 워크 플로우 rebase와 cherry-pick여전히 특별한 경우에 유용합니다 :
- 한 가지 단점
merge은 혼란스러운 역사입니다. rebase정기적으로 다른 사람의 변경 사항을 병합하는 경우처럼 커밋이 기록에 흩어지지 않도록합니다. 그것이 실제로 내가 사용하는 주요 목적입니다. 당신이 매우 조심 하고 싶은 것은 rebase다른 저장소와 공유 한 코드 를 작성 하지 않는 것 입니다. 커밋이 끝나면 push다른 누군가가 그 위에 커밋했을 수 있으며, rebasing은 위에서 설명한 것과 같은 종류의 복제를 유발할 것입니다. 최악의 경우 매우 혼란스러운 저장소와 미묘한 오류가 발생하여 페럿을 제거하는 데 시간이 오래 걸립니다.
cherry-pick 은 기본적으로 삭제하기로 결정한 주제 브랜치에서 작은 부분의 변경 사항을 샘플링하는 데 유용하지만 유용한 부분이 몇 가지 있다는 것을 깨달았습니다.
하나 이상의 변경 사항을 병합하는 것을 선호하는 경우 훨씬 간단합니다. 개별 변경 세트를 많이 시작하면 개별 변경 세트를 병합하는 것이 매우 지루할 수 있습니다. git (및 Mercurial 및 Bazaar)의 병합 해상도는 매우 좋습니다. 대부분 긴 지점을 병합하는 데 큰 문제가 발생하지 않습니다. 나는 일반적으로 모든 것을 한 번에 병합하며 , 충돌이 많은 경우 에만 병합 단편을 백업하고 다시 실행합니다. 그럼에도 불구하고 나는 큰 덩어리로 그것을합니다. 매우 실제적인 예로서 저는 3 개월 동안 합병해야 할 동료가 있었고 250000 라인 코드 기반에서 9000 번의 충돌이있었습니다. 우리가 고 쳤던 것은 한 번에 한 달 동안 합병하는 것입니다. 충돌은 선형으로 쌓이지 않고 조각으로 수행하면 훨씬 큽니다.9000 미만의 충돌. 그것은 여전히 많은 작업 이었지만 한 번에 한 번의 커밋을 시도하는 것만 큼은 아닙니다.