SVN 설치 및 재 통합 기능

Question

고객이 우리가 개발중인 소스 코드를 갖고 싶어합니다. 그 일환으로, 그들은 SVN을 선택했습니다. 그들은 우리가 결국 코드를 ​​개발하기를 원합니다.

그들은 다음과 같은 구조를 가지고 있습니다. 알파벳은 가지를 나타냅니다. DEV 분기가 코드 누적으로 완료되면 QA 팀이 해당 코드에서 테스트를 시작할 수 있도록 QA라는 새 분기가 해당 코드를 갖기를 원합니다. 개발자가 버그를 발견하면 DEV 팀은 DEV 지점의 코드를 업데이트하고 QA는 해당 코드를 DEV와 다시 동기화합니다.

마지막으로 코드가 프로덕션으로 릴리스되며 버그가있는 경우 DEV-QA-Prod주기가 다시 수행됩니다.

A->B [DEV]---------- 
|\ |    | 
| C [ QA ]  | 
|     | 
|_______D[ PRODUCTION ] 

우리는 상대적으로 SVN을 처음 사용합니다. 그래서 우리는 이와 관련하여 몇 가지 질문을합니다.

1. 일단 QA를 사용하는 것이 좋습니다. B와 C는 모두 동일한 코드 기반을가집니다. 이 점을 감안할 때 어떤 지점을 다시 A로 통합해야합니까? 그것은 B입니까 아니면 C입니까? 아니면 둘 다 똑같은 것을 가지고 있어도 전혀 문제가되지 않습니다.

2. 사실 C 인 경우, 다른 지점 [B]의 지점 [C]을 부모 [A]에게 직접 재 통합 할 수 있습니까?

감사합니다. Pavan. enter code here

Answer 1

QA가 단순히 버그를 기록하고 실제로 코드를 건드리지 않고 분기에 수정 사항을 커밋하지 않으면 나는 QA 분기를 생성하지 않습니다. QA에게 지점 DEV에 대한 읽기 전용 액세스를 제공하지 않는 이유는 무엇입니까? 그러면 DEV 분기를 trunk으로 병합하기 만하면됩니다. 그들이 수정을 투입되기 때문에 대신 QA 이이 DEV 떨어져 자신의 지점이 필요없는 경우

후 병합 경로가 있어야한다 : QA -> DEV -> trunk.

trunk 분기 이후 PROD 분기를 만드는 이유가 확실하지 않습니다. 간단히 tag trunk에 버전 번호 나 이름과 같은 이름을 붙이면 어떨까요? 그런 다음 원래 DEV 분기에서 개발이 진행되고 프로덕션 환경에서 버그가 발견되면 DEV의 다음 릴리스 (수정 이후 trunk으로 병합 됨)에서 픽스를 롤링하거나 별도의 DEV 분기를 만들 수 있습니다 태그가 추가 된 버전에서 trunk을 해제하고 수정 사항을 적용하십시오.

희망이 도움이됩니다.

Answer 2

개발 점검으로 trunk을 사용하십시오. trunk의 코드는 버그 수정과 '안전한'개발이 수행되는 주 복사본이어야합니다.

일단 QA가 작업을 수행하게하려면 새 태그를 작성하여 버전/빌드 번호를 부여하십시오.

QA가 버그를 발견하면 트렁크의 코드가 수정됩니다. QA 테스트가 실행되는 동안 트렁크에 대한 추가 개발 작업을 수행해야합니다. 버그가 수정되면 새 태그가 만들어지고 QA 테스트를 다시 실행해야합니다.

QA 테스트/버그 수정주기가 실행되는 동안 새 기능을 개발하려면 모든 버그 수정을 통합하기 위해 새 분기를 만들어 트렁크에서 자주 병합해야합니다. 브랜치에서 트렁크로 병합하고 새 태그를 만드는 것으로 구성됩니다. 등등.

QA는 svn switch 명령을 사용하여 태그에서 다른 것으로 이동할 수 있습니다. 코드를 작성하지 않았다고 가정합니다. 태그는 작성된 후에 수정되지 않는 것을 의미합니다.