의존하는 토픽 브랜치 분기

git에서 많은 토픽 브랜치 브랜치를 사용하고 때로 리베이스 문제를 일으키는 토픽 브랜치 간의 의존성으로 끝납니다. 예를 들어, 같은 구조 : 때문에 이후 다음, featureA을 리베이스 featureA가 (뿐만 아니라 때로는 흥미 진진한 새로운) 같은 충돌을 트리거에 featureB을 리베이스 때의존하는 토픽 브랜치 분기

master ---> featureA ---> featureB 
        \--> featureC

master하는 경우 변경 전 (및 해결) 충돌을 얻을 패치는 featureA 브랜치의 패치를 다시 적용하려고 시도합니다. 실제 패치가 featureA과 featureB 사이 인 경우 cherry-picked를 적용하면 벚 체리와 거의 동일한 효과로 rebase를 수행 할 수 있습니다. featureA과 featureB 사이의 모든 커밋을 선택합니까?

출처

2009-10-10 Kai

참고 [전체 하위 작업을 리베이스하는 방법 - 여러 분기, 병합 결과로 일부 링크가 있음] (http://stackoverflow.com/a/9706495/94687). 이 솔루션의 불쾌한 부분은 나중에 주제별 분기 참조를 새 rebased 커밋으로 다시 설정해야한다는 것입니다. –

featureA을 리베이스 후에는

git rebase --onto featureA oldFeatureA featureB

가 oldFeatureA 당신이 그것을으로 업데이트하기 전에이 (당신이 거기에 또 다른 지점을 유지하거나 해시를 커밋 기억 할 수 있습니다) featureA의 끝에서 커밋 나타냅니다 가정 할 수 있습니다.

이것은 기본적으로 동일해야 체리 따기 각각 A.

Documentation on git-rebase의 리베이스 버전에 A 및 B 사이에 커밋 (좀 더 복잡한 REBASE 동작 동안 일어나는 몇 가지 유용한 화보 설명 포함)

출처

2009-10-10 00:33:32 Phil

우수, 감사합니다. 나는 그것이 일을해야하는 것처럼 보였다. 그러나 오래되었던 팁을 기초로서 사용하는 것은 나에게 일어나지 않았다. – Kai

'oldFeatureA' 대신에, rebase가 해당 branche의 마지막 변경이라고 가정하고'featureA @ {1}'을 사용할 수 있어야합니다. 그렇지 않으면'@ {2}','@ {3}','@ {1 시간 전} '과 같은 것을 사용하십시오. – Ropez

미래에 상호 의존적 인 토픽 브랜치를 많이 사용한다면 아마도 지트의 토픽 브랜치와 브랜치마다 하나의 패치를 사용하여 패치 큐를 관리하는 도구 인 TopGit (README)의 사용을 고려해야합니다. 또는 대안으로 여러 주제 분기를 관리하는 도구입니다.

topgit Means Never Having to Wait for Reviews 블로그 게시물

출처

2009-10-10 07:38:05

TopGit을 가르쳐 주셔서 감사합니다! TopGit은 상호 의존적 인 지사를 유지하는 것, 즉 올바른 것을 목표로 삼는 것으로 보인다. ** 그러나 TopGit에는 상호 의존적 인 주제 분기를 새로운 업스트림 상태로 리베이스 할 수있는 기능이 있습니까? ** 가능하다면 TopGit을 사용하여 패치를 개발하고 분기를 준비하고 업스트림에 의해 끌어 올 수 있습니다. –

또한보십시오 [ "rebase-based TopGit"에 대한 토론 (http://git.661346.n2.nabble.com/Branch-dependencies-td6641429.html) : "새로운 '시스템'이 필요하다고 생각합니다. 'rebase'기반, TopGit처럼 병합하지 않음 " –

의존하는 토픽 브랜치 분기

답변

관련 문제