이미 여러 번 질문했지만 신속하고 완전한 대답을 찾을 수 없었던 것 같습니다.TFS를 사용하여 여러 릴리스에서 올바르게 분기하는 방법
처음부터 시작해서 다르게 진화 할 수있는 두 가지 병렬 릴리스를 사용하기 위해 TFS 프로젝트를 설정하려고하지만 여전히 두 가지 모두에 버그 수정을 적용 할 수 있기를 원한다면 REL이라고 부르 자. A와 REL. B는 둘 다 코드 변경을 공유하지 않지만 REL의 버그 수정 일 수 있습니다. A가 REL에 푸시되어야합니다. B.
처음부터 메인 또는 개발자를 먼저 생성하고 다른 하나는 어떤 분기입니까?
REL. A는 Dev 또는 Main의 지점입니까?
REL. B는 REL의 한 지점입니다. A 또는 Main 또는 Dev?
감사합니다.
확인. 이를 바탕으로 다음과 같이 제안합니다.
이들은 서로 다른 제품이기 때문에 지점 별 제품 접근 방식을 사용할 수 있습니다. 이 접근법에서는 다음과 같이 나타납니다.
MAIN - 기준 코드.
BugFix - 메인에서 브랜치. (공유 버그가 수정되는 곳입니다)
제품 A - 메인에서 분기됩니다.
제품 B - 메인에서 분기.
내가
작업의 대부분에서 수행 될 다음 "데브"지사는 버그 수정, 제품 A의 각 떨어져 분기 추천하고, 제품 B 지점 (단지 좋은 SCM 관행에 대한) 것을 귀하의 제품이 나옵니다. 버그를 수정해야한다면, BugFix 브랜치에서 코드를 작성하고 테스트하는 것이 가장 이상적입니다. "루트"코드로 작업 할 수있는 것으로 인증되면 해당 수정 사항을 MAIN에 병합 한 다음 제품 A와 제품 B로 병합합니다.
덜 이상적인 상황에서 제품에서 버그가 수정 된 경우 A와 B 제품에 반영해야 할 경우 제품 A에서 MAIN으로, 그리고 MAIN에서 제품 B 및 BugFix로 해당 코드를 체리 선택하십시오. 실수로 제품 A의 기능을 제품 B로 병합 할 수 있다는 점에서 위험한 접근 방식입니다.
Microsoft는 Visual Studio Team Foundation Server Branching and Merging Guide을 사용하여 분기 구조를 선택할 수 있습니다.
릴리스 A와 릴리스 B의 코드가 결국 병합 될 것입니까? 아니면 릴리스 A가 릴리스 B와 항상 다른 제품이 될 것입니까? – Robaticus
은 항상 다른 제품이지만, 버그가 지점 앞과 양쪽에서 공유되는 공통 부분에있는 경우 모두 버그 수정을 전파하기 위해 공통 루트가 필요합니다. –