버전 1.1과 버전 2.0에서 동시에 작업하려면 어떻게 해야 합니까?

Question

그 상황:베타 버전이 종료되었으며 버전 1.0이 여러 고객 사이트에 출시되었습니다.A팀은 이미 점진적인 버그 수정과 유용성 조정이 포함된 버전 1.1 작업에 바쁜 반면, 다른 팀은 제품의 핵심이 완전히 재설계되었을 수 있는 대규모 변경 사항이 포함된 버전 2.0 작업을 진행하고 있습니다.이제 1.1에 적용된 대부분의 변경 사항은 어느 시점에서는 2.0에 적용되어야 하며, 2.0 브랜치에서 이루어진 버그 수정 중 일부는 실제로 이전 릴리스에 적용되어야 할 수도 있습니다.문제는 2.0에는 근본적인 차이점이 있기 때문에 수동 변환 없이는 1.1의 변경 사항을 병합할 수 없으며 그 반대의 경우도 마찬가지라는 것입니다.

내 질문:이런 상황에서 병합 충돌과 중복 작업을 최소화하기 위한 최선의 개정 관리 방법은 무엇입니까?우리 팀이 개정 관리 문제에 가능한 한 적은 시간과 노력을 쏟으면서도 고객에게 정기적인 패치를 제공하도록 하려면 어떻게 해야 합니까?

Answer 1

한 가지 좋은 방법은 stable 브랜치의 각 버그를 수정하고 stable 브랜치를 개발 브랜치에 병합하는 것입니다.이것이 병렬 유지보수/개발 라인 패턴이 중요하며, 핵심은 조기에 자주 병합하는 것입니다.드물고 늦게 병합한다는 것은 개발 브랜치가 안정적인 브랜치에 비해 인식할 수 없거나 버그가 같은 방식으로 반복될 수 없다는 것을 의미합니다.

파괴 버전 1.5부터 병합 추적이 포함되어 있으므로 동일한 변경 세트가 두 번 병합되어 어리석은 충돌이 발생하지 않도록 할 수 있습니다.다른 시스템이 존재합니다(예: 힘내, 수은제, 아큐레브, 억지로) "지점 A의 어떤 변화가 분기 B에 병합되지 않았습니까?" 그리고 Cherry-Pick Dev Branch까지 필요한 수정 사항.

Answer 2

기사 여기 (Day-today with Subversion)에서는 버전 1.1 빌드의 데이터로 버전 2를 지속적으로 업데이트하는 방법 중 하나가 언급되어 있습니다.기사에서 그 사람은 매일 이렇게 하라고 하더군요.

당신이 읽고 싶은 부분은 "웨이터, 내 트렁크에 벌레가 있어요!"라는 제목입니다.기사가 절반쯤 왔네요.

Answer 3

아마도 이 목적을 위해 문제 추적 시스템에 의존하고 트렁크 코드로 전달해야 하는 각 변경 사항에 태그를 지정해야 합니다.그런 다음 각 변경 사항에 대한 체크인 주석이 관련 문제를 참조하는지 확인하고 트렁크에서 다시 구현하려고 할 때 쉽게 이해할 수 있도록 코드 변경 의도를 명확하게 표현할 수 있습니다.

Answer 4

다른 사람들이 말한 것과 거의 비슷하지만, 저는 SVN을 사용하여 여러 지점에서 개발을 처리한 경험을 바탕으로 삼을 것이라고 생각했습니다.

우리의 주요 제품에서는 동시에 2개 이상의 버전을 개발해야 합니다.

나는 원래 메인 트렁크를 "메인 개발" 버전으로 사용했고, 각 실제 릴리스에 태그가 사용되었습니다.새로운 기능 세트를 위한 실질적인 개발 노력에 브랜치가 사용되었습니다.그러다가 나중에 한 번에 2, 3, 4개 릴리스 작업을 시작하면서 각 개정판마다 브랜치를 사용하기 시작했습니다.

저장소를 유지 관리하고 QA 빌드 푸시도 처리하므로 매일 아침 "롤업"을 수행합니다. 이는 현재 가장 낮은 활성 분기부터 시작하여 트리의 변경 사항을 병합하는 작업으로 구성됩니다.그래서 결국 1.1의 변경 사항을 1.2로 병합하고, 이는 마지막 병합 이후 1.2의 다른 변경 사항과 함께 1.3으로 병합됩니다.

커밋할 때 항상 커밋에 다음과 같은 주석을 달도록 합니다.

1.1 개정판 5656-5690 병합

조금 아플 수도 있지만 효과가 있어요 :)

Answer 5

일찍 병합하고, 자주 병합하고, 메인라인의 QA가 유지 관리 릴리스의 각 패치에서 수정된 결함을 알고 재발/검증하는지 확인하십시오.

다음 릴리스에서 뭔가 빠져나가거나 버그를 "수정"하는 것은 정말 쉽습니다. 고객은 여러 지점을 관리하는 것이 얼마나 복잡해지는지 신경 쓰지 않습니다. 그게 바로 여러분의 일입니다.

분기 및 병합을 지원하는 소스 제어 시스템을 사용하고 있는지 확인하십시오(저는 Perforce 및 SVN을 사용해 본 적이 있으며 Perforce가 더 좋지만 SVN은 무료입니다).

또한 일관된 방식으로 병합을 수행하는 책임을 한 사람에게 두는 것이 병합이 정기적으로 수행되도록 하는 데 도움이 된다고 믿습니다.일반적으로 저나 우리 팀의 선배 중 한 사람이었습니다.

Answer 6

내 작업에서 이를 처리하는 방법은 트렁크 분기를 가장 최첨단 코드(예: 이 경우 2.0)로 유지하는 것입니다.1.x 코드에 대한 분기를 만들고 거기에서 모든 수정 작업을 수행합니다.1.x에 대한 모든 변경 사항은 트렁크(2.0) 분기에 병합되어야 합니다(필요한 경우 수동으로).

그런 다음 1.x 개발자는 해당 버그 티켓에 1.x 커밋의 개정 번호와 2.0 병합의 개정 번호를 모두 기록해 두라고 주장합니다.이렇게 하면 변경 사항을 병합하는 것을 잊어버린 사람이 있는지 쉽게 알 수 있으며, 이를 추적해야 한다는 사실이 기억하는 데 도움이 됩니다.

Answer 7

한 가지 핵심 포인트가 포착되었습니다. 이 사진 빌드 닥터에서:한 방향으로만 병합합니다.

Answer 8

이 특정 질문에 답하기 위해 많은 개발자가 Subversion에서 Git으로 전환했습니다.github.com을 확인하세요.