여러 개발자간에 트렁크/분기 및 태그 구조 사용

Question

트렁크/분기 및 태그와 관련하여 혼란스러워집니다. 다음은 나의 질문입니다.

우리는 단일 프로젝트로 작업하는 개발자 팀이 있습니다. 개발자는 종종 그룹으로 나뉘며 동일한 프로젝트의 여러 모듈에서 작업합니다.

현재 모든 사용자가 동일한 로컬 서버에서 작동하고 파일을 커밋하는 간단한 SVN 시스템 (트렁크/분기 또는 태그 없음)이 있습니다. 그러나이 문제는 몇 명의 개발자가 향후 모듈에서 작업 할 때 시작됩니다.이 모듈은 즉시 작동하지 않아야합니다. 이 경우 데이터를 커밋 할 수는 없습니다. 그렇다면 개발 코드가 라이브 서버에 업로드되어 모든 것을 엉망으로 만들 것이기 ​​때문입니다.

그래서 이제는 개발자가 동일한 코드에서 별도로 작업 할 수있는 솔루션을 찾고 있습니다. 이런 식으로 뭔가 :

개발자 A가 새로운 모듈 A 개발자 B에 노력이 모듈 C의 버그 수정에 노력하고 새로운 모듈 B 개발자 C에 노력하고 있습니다 (라이브하지만 몇 가지 버그에 이미 수정해야합니다)

따라서 개발자 A는이 컴퓨터에 자체 복사본을 가지고 개발자 A의 저장소에 커밋합니다. (또는 지점)

동일한 논리가 개발자 B에 적용되지만 개발자 C는 태그의 어딘가에있을 것입니다. 그러면 개발자 C가 태그의 어딘가에있을 일반 안정적인 복사본에서 작업하게됩니다. 작업이 완료되면 태그가 추가되어 해당 태그의 트렁크에 푸시됩니다. 라이브 서버에 업로드하십시오.

개발자 A가 작업을 완료하면 모든 파일을 라이브 업로드를 위해 트렁크로 푸시합니다. (이것은 트렁크의 일부 공통 파일도 병합해야합니다). 개발자 B에도 동일한 로직이 적용됩니다.

SVN이 올바른 해결책인지는 확실하지 않습니다. 나는 내가 원하는 것을 구현할 수있는 더 간단한 방법이 있는지조차 모른다.

모든 종류의 제안을 환영합니다.

감사 TTR

Answer 1

내 의견으로는 첫째로 모두의 devs 프로젝트의 별도의 조각에서 작업하는 경우, 당신은 멀리 지사와 함께 할 수 있다는 것입니다. 그것은 약간의 조직 (예 : 적절한 로그 주석 및 버전 관리)을 취할 수도 있지만, 이는 분기 및 병합보다 훨씬 덜 번거 롭습니다.

좋아,하지만 네가 가지를 원한다면 쉽지. 여기에는 몇 가지 접근법이 있지만 기본적으로 모두 최종 코드가 끝나는 '마스터'버전이 필요합니다. 이것은 트렁크 일 수 있거나, 일부 사람들은 트렁크를 변경 한 다음 분기를 릴리스하기 위해 코드를 병합하는 것을 선호합니다. '트렁크 마스터'는 가장 이해하기 쉬운 컨셉입니다.

svn에서 브랜치를 만드는 것은 쉽습니다. 저렴한 복사본이므로 문제가있는 디렉터리를 채우는 것이 좋습니다. 일단 완료되면 브랜치를 삭제하는 것이 좋습니다. SVN은이 유형의 작업을 위해 특별한 종류의 브랜치 (reintegration branch)를 제공합니다. SVN은 트렁크에서 분기를 작성하고, 작업하고, 때때로 트렁크에 대한 변경 사항으로 업데이트 한 다음, 해당 분기의 모든 작업을 트렁크로 다시 통합하도록 설계되었습니다. 마지막 쾅. 그런 다음 다시 시작할 수 있습니다. 이것이 당신이 원하는 것일 수있는 것처럼 들리지만 일반적으로 개발자 당 지사를 가지지 않을 것입니다. 작업 패키지마다 지점이 있습니다.

dev-dev 브랜치의 문제는 브랜치의 수명이 길어질수록 변경 사항이 병합되기가 더 어려워지고 힘들어진다는 것입니다. 개발자가 다른 개발자의 작업을 정기적으로 해당 지사에 병합하지 않는 경우 (예 : 할 수 없듯이) 특히 그렇습니다.

svn은 값싼 복사본을 만들므로 각 개발자를 위해 전체 트렁크를 분기하는 것이 좋습니다. 필자는 개별 디렉토리를 분기하는 대신 기억하는 것이 더 쉽다는 것을 알았습니다. 공유 파일이나 공용 파일을 커밋하면 다른 분기가 파손될 수 있으므로 걱정할 필요없이 항상 공유 파일이나 공통 파일을 변경할 수 있습니다. (예 :/trunk/moduleA를 분기하고 나중에/trunk/include/common_file을 변경해야하는 경우 공통 파일이 하위 집합을 분기 할 때 분기에 있지 않게됩니다. t 추가 비용이 필요합니다)

Answer 2

전체 트렁크/태그/브랜치 모델의 근본적인 이유는이 상황을 정확하게 관리하기위한 것입니다.이 상황은 개발 샵이 정상적으로 처리 할 수있는 상황입니다 잠시 후.

트렁크없는 모델에서 트렁크 모델로 마이그레이션하는 것이 한 가지 계획입니다. 를 분기하려고하지 않는 - 경고

/ 
filea.html 
fileb.html 
dira/ 
    filex 

단어 :

당신은 그래서 당신의 모델은 다음과 같이 보입니다 가정 등, 당신이 어떤 트렁크, 태그, 지점이없는 말 루트 디렉토리 자체는입니다.

예 :

svn cp//branchA 

이의 모습 디렉토리 초래 : 루트 분기 및 하위 가지의 일부가 꽤 빨리 꽤 어려운된다 무엇 Unpicking

/ 
filea.html 
fileb.html 
dira/ 
    filex 
branchA/ 
    ... 
branchB/ 
    ... 

.

깨끗하게 유지 - 모든 코드를 먼저 트렁크로 옮깁니다.

svn cp /trunk /branches/branchA 

: 당신이 당신의 가지를 만들 수 있습니다 지금

svn cp//trunk 

이 자신의 작업 공간을 삭제하고 깨끗한에서 모든 것을 얻을 모든 사람 (모든 배포 시스템)이 필요합니다 구조 점프의 종류 지점이 완료되면, dev에의 그들을 확인하고 작업 할 수

/ 
trunk/ 
    filea.html 
    fileb.html 
    dira/ 
    filex 
branches/ 
    branchA/ 
    ... 

:

처럼 당신에게 구조를주기. 배포 시스템은 루트 폴더 대신 트렁크 /를 가리켜 배포 할 수 있습니다.

bug-fixes를 사용하는 개발자는 checkout 트렁크를 사용할 수 있습니다. 그들이 커밋 할 때 배포 시스템은 지금처럼 변경 사항을 배포합니다.

branchA가 완료되면 devs는 gbjbaanb가 제안한 것처럼 변경 사항을 트렁크에 병합 할 수 있습니다.

머리가 빨리 올라간다. 행운을 빈다.