git work : 쓰고 버리는 병합과 git-rerere - 요점은 무엇입니까?

Question

Git을 처음 접하는 대부분의 사람들처럼 git merge와 git rebase에 적용 할 수있는 유스 케이스를 해독하려고 혼란을 겪고 있습니다. 나는 결과적으로 작업 카피 상태에 이르기까지, 당신에게 똑같은 것을주는 것을 마침내 결정했다고 생각합니다. 또한 둘 다 동일한 갈등을 낳습니다. 이것이 틀린 경우, 저에게 계몽의 모범을 보이십시오.

제 생각에 병합 대신 rebase를 사용하면 (변경 사항을 푸시 또는 풀지 않은 경우) 내역을 선형으로 유지하는 것이 가장 좋습니다. 내가 정말로 이해하지 못하는 것은 git-rerere를 개발하는 이유이다.

맨 페이지에서 git-rerere는 이전에 해결 한 충돌을 해결하려는 경우에 도움이 될 것으로 예상됩니다. 참조하려는 예제는 http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html입니다.

프로젝트의 정책이 mainline의 변경 사항을 (Linux 커널과 같은) topic 브랜치로 지속적으로 병합하지 않는다면, 위의 예제는 "throw-away"merge 커밋을 생성한다고 말합니다. 근본적으로 마스터를 주제에 병합하고 테스트를 실행하여 모든 것이 제대로 작동하는지 확인한 다음 병합 커밋을 버리는 "git reset -hard HEAD ^"를 수행하십시오. 나중에 다른 "throw-away"병합 커밋을 만들 때 git-rerere는 frst throw-away 병합에서 이미 해결 한 충돌을 해결하는 데 도움을줍니다.

누군가가 일시적인 병합 커밋을 만드는 데 어려움을 겪지 않고 개발자가 자신의 주제를 마스터에 리베이스하지 않을 이유를 설명해 주실 수 있습니까? 그것은 자식 - rebase의 요점이 아닌가? 변화를 얻지 만 병합을 피할 것인가? 이것은 동일한 일을 성취하지 않으며, 아무도 주제 분기 변화를 가져 오지 않는다고 가정하면 훨씬 간단한 방법이 아닌가? 변경 사항을 푸시/당겼을 때 쓰래드 - 멀리 - 병합 + git-rerere 워크 플로우가 실제로 있습니까?

마지막 질문 하나 - Linus는 "로그에 'Merge branch linus'가 많이 표시된다면 나무가 분명히 임의의 쓰레기를 가지고 있기 때문에 나는 여러분에게서 끌어낼 수 없습니다. 그곳에 있으면 안됩니다 ... "리누스도 지속적인 리베이스에 문제가 있습니까?

Answer 1

리베이스와 병합이 동일한 최종 트리를 생성 할 수 있다고 맞습니다. 그들이 생산하는 역사는 매우 다르지만 버전 관리는 물론 역사에 관한 것입니다. 선형 역사에 대한 선호도를 표명했습니다. 이는 지역 규모에서 실제로 바람직합니다. 병합은 기능, 버그 수정 등의 대규모 상호 작용을 기록하는 데 도움이됩니다.

중앙 질문에 대한 간단한 대답 (왜 rebase가 아닌가?)은 지점이 시작될 때가있을 때가 있고 때가되면 rebase가 아니라 병합해야합니다.

예를 들어, 유지 보수 릴리스 및 현재 릴리스에 적용되는 버그 수정이있을 수 있습니다. 두 릴리스의 조상 인 최신 커밋에서 분기하려고합니다. 해당 분기를 마스터 또는 유지 보수 분기를 따라 앞으로 리베이스 할 수 없거나 더 이상 다른 분기로 병합 할 수 없습니다.

마찬가지로 모든 주제 분기는 어딘가에서 시작됩니다. 어떤 시점에서, 당신은 그 역사를 보존하고 싶습니다. 명확한 사례 중 하나를 언급했는데 (다른 사람들은 당신의 연구를 끌어 냈습니다), 그러나 그것은 훨씬 덜 분명 할 수 있습니다. 어쩌면 다른 기능과의 상호 작용이있을 수 있습니다.이 기능에는 하위 기능이 있으며 전체 계층 구조를 보존하려고합니다.

브랜치가 로컬이고 브랜치를 고정 할 이유가 없으면 브랜치를 리베이스하고 완료하는 것이 훨씬 간단합니다. 그러나 때로는 그렇게하는 것이 옳지 않습니다.

마지막 질문은 실제로 매우 다른 내용이나 병합 충돌과 관련이 없습니다. Linus는 을 수행 할 필요가없는 의 병합 중 in the context을 말했습니다. 이것은 분기 및 병합 철학의 문제입니다. 주니 오 하마노 (Junio ​​Hamano)는 바로 그 문제에 대해 excellent blog post이라고 썼다. 손에 주제를 요약 한 간략한 인용 :

당신이 주제 분기를 병합 할 때 '마스터'지점에 '- frotz 추가', 당신은 분명 더 중요한 것은 새로운 'frotz'기능을 포함되지만,

, 당신이하는 것이 바람직하다 것을 주장하는 그 '마스터'분기 'frotz'기능

리누스는 '리누스'의 모든 시간이라는 이상한 분기를 병합보고 싶어하지 않는

때문에 명확하게 ' 당신의 지부에있는 것이 바람직한 특정 주제를 병합하지 마십시오. 업스트림 브랜치를 토픽 브랜치에 반복적으로 병합하는 것은 완전히 잘못된 방향입니다. 마스터 (또는 리누스)의 모든 것을 주제로 개발할 필요는 없습니다. 주제를 끝내고 다른 방법으로 병합해야합니다. 업스트림은 마스터로 업스트림입니다. 주제 분기에 마스터의 모든 컨텐츠를으로 갖는 것은 바람직하지 않습니다. (그리고 한 개발자의 주인은 정말로 통합 자에 관한 한 주제 분기입니다.)

그래서 Linus는 자주 병합하는 데 문제가 없습니다. 그는 목적없는 그리고 비생산적인 합병에 대한 문제가있다. (그리고 일반적으로 합병이 좋은 이유로 행해지면 빈번하지 않을 것이며 하류 합병은 거의 없을 것입니다.) 합당한 이유로 리베이스가 끝나고 역사를 만듭니다 더 나은, 그럼 그들은 좋은 일이지만 자주.

Answer 2

동일한 작업을 수행하지 않으며 주제 분기 변경 사항을 가져간 사람이 없다고 가정하면 훨씬 간단한 방법이 아닌가? 변경 사항을 푸시/당겼을 때 쓰래드 - 멀리 - 병합 + git-rerere 워크 플로우가 실제로 있습니까?

당신은 머리에 못을 박았습니다. 재 게시는 아직 게시하지 않은 지점에 유용합니다. rerere은 게시 한 지점 (즉, 리버스가 부적절하거나 다운 스트림 개발자에게 짜증나는 지점)에 유용합니다.

리누스도 지속적인 리베이스에 문제가 있습니까?

아니요, 리베이스를 수행해도 병합 커밋이 발생하지 않으며 기본적으로 분기가 리베이스 된 것을 볼 수 없지만 분기가 다른 분기에 여러 번 병합되었는지 쉽게 확인할 수 있습니다.

Answer 3

기능별 워크 플로마다 임시 통합 분기가 권장됩니다. 이러한 시나리오에서 리베이스하면 최종 버전에서 다른 체크인을 설정할 수있는 임시 분기에 대해 리베이스 (또는 당겨)해야합니다. 귀하의 리베이스를 실제로 쓸모 없게 만듭니다. 또는 당신이 당신의 지사를 당기게되면 그 당김이 쓸모 없게 될 수도 있습니다.

반복적 인 병합 통증 완화에 큰 도움이됩니다.