10
우리는 역사에 대해별로 신경 쓰지 않는다고 주장합니다.힘내 : 마스터를 주제 분기에 병합하면 나중에 충돌을 피할 수 있습니까?
다소 자주 업데이트되는 마스터 브랜치가 있고 공유 된 토픽 브랜치가 오랜 수명을 지닌 경우 정기적으로 마스터 -> 토픽 브랜치를 병합하여 발생하는 충돌을 해결하여 주제 분기 -> 마스터 나중에 원활하게 병합?
A
답변
7
당신이 말하는 것은 논란의 여지가 없습니다. 메인 브랜치에서 사이드 브랜치로 변경 사항을 정기적으로 병합 (백 포트)하면 사이드 브랜치를 메인으로 다시 병합 할 때가 있습니다. 할 일이 많습니다.
물론, 맞습니까? 시간이 지남에 따라 지점이 분기됩니다. 그리고 오늘 코드를 작성하는 방법은 어제 쓴 방법에 달려 있습니다. 당신의 가지가 오늘 갈라지면 많을수록 내일 갈라지기 마련입니다.
메인 브랜치에서 리팩토링하는 사람에게 몇 가지 코드가 있다고 가정 해보십시오. 사이드 브랜치에서 리팩토링 된 코드를 사용하는 새로운 기능을 구현해야한다고 가정 해보십시오. 리팩토링 변경 사항을 병합 (백 포트)하기 전에 새 기능을 작성한 다음 새 기능을 메인 브랜치로 이식하려는 경우 a) 사전 리팩터링 코드를 기본 코드로 다시 추가하거나 b) 새 기능을 리팩터링하십시오. 이미 리팩터링을 병합 (백 포트) 한 경우 새 기능을 모든 작업 없이도 주 기능에 병합 할 수 있습니다.
아닙니다. 하지만'git checkout topic; git rebase master' 모두 잘 작동합니다. – glebm
도움이 될만한 도구가 있습니다. [성공적인 Git 브랜치 모델] (http://nvie.com/posts/a-successful-git-branching-model/) –
@glebm OP는 그것이 _shared_ topic 브랜치라고 언급한다. 'git rebase'는 지사가 없기 때문에 조심하지 않으면 재앙이 될 수 있습니다. _local_ 가지에서'git rebase'가 제가 선호하는 방법입니다. 오, 그래, –