2012-06-07 6 views
1

저는 최근에 새로운 일을 시작했으며 지금까지는 개발자 한 명만있었습니다. Subversion과 함께 Eclipse와 Collabnet 사용하기. 그래서 그는 충돌 등의 문제가 없었습니다. 원래 응용 프로그램을 완전히 다시 작성하므로 다른 코드와 충돌이 없습니다.SVN에서 단일 개발자에서 복수로 이동

이렇게하면 아무런 문제없이 (컴퓨터가 "죽은"경우) 언제든지 커밋 할 수있었습니다.

SVN 디렉토리가 트렁크없이 구축되었습니다. 모든 것은 루트 디렉토리에 직접 있습니다.

이제 개발자가 3 명 있습니다. 나는 여전히 매일 저 지르지 만 다른 사람들의 일을 방해하지 않기를 원한다. 그래서 지금 트렁크를 생성 한 다음 각 개발자마다 별도의 브랜 크를 작성하는 것이 올바른 방법이라고 가정합니다. 그 맞습니까?

만약 그렇다면 가장 쉬운 방법은 무엇입니까? 나는이 링크를 보았지만 아주 오래되었고 새롭고 쉬운 방법이 있는지 궁금합니다. Is there a clean way to move/to /trunk?

+2

Git 또는 Mercurial로 마이그레이션하기에 좋은시기입니다. –

답변

2

자주 커밋하고 업데이트하십시오.

코드의 다른 섹션을 작성하거나 편집하지 않는 한 충돌이 발생해야합니다. 갈등이 조기에 발생할수록 (따라서 작아지면) 좋을 것입니다. 매일하는 것은 충분하지 않습니다.

커밋은 근본적인 변경이 이상적입니다. 가능한 가장 작은 변화로 안정성과 정확성을 유지하면서 코드에 무언가를 추가합니다. 즉, 3 가지 다른 기능을 추가 한 다음 커밋하면 커밋이 충분히 작지 않을 가능성이 높습니다. 각 기능에는 자체 커밋이 있어야합니다. (또는 기능 중 하나라도 작지 않은 경우 커밋이 두 번 이상 발생할 수 있습니다.)

이상적으로 변경 사항을 전달할 의사가 있어야합니다. 실제로 얼마나 잘 작동하는지는 많이 다릅니다. 그러나 프로그래머 A가 모듈 X에서 작업 할 것이라는 것을 알고 있다면 필요하지 않으면 모듈 X 코드를 수정하지 않는 것이 좋습니다.

루트를 움직이는 방법은 내가 아는 한 실제로는 여전히 권장되는 방법입니다. 한 번만 해보면 큰 문제가 아닙니다.

편집 : 나는 아마 svn-workflow 전문가가 아니라고 언급해야합니다. 저는 약 6 개월 동안 git을 사용하는 4 명 팀과 몇 년 동안 svn을 사용하는 2 명 팀에서 일했습니다. 이 게시물은 내가 알아챈 것 또는 시간이 지남에 따라 우리를 다치게 한 것에 근거합니다.

+0

부분적으로 완료된 항목을 커밋 할 수 없습니다. 코드가 아직 작동하지 않을 수도 있지만 워크 스테이션에 백업이없고 SVN 서버가 있기 때문에 개발자가 코드를 안전한 장소에두기를 원합니다. – theblitz

+0

@theblitz 부분적으로 완료된 방법에 따라 부분적으로 완료된 것들은 대개 커밋되지 않아야합니다. 각 개정판은 의미있는 소프트웨어 수정을 대표해야합니다. 커다란 지형지 물이 의미하는 바는 클라이언트가 논리적으로는 1 가지 기능이지만 코드 측면에서는 여러 부분 (예 : 복잡한 검색 페이지는 기본 검색 페이지를 가질 수 있습니다. 커밋 된 후 나중에 커밋 된 검색 페이지). – Corbin

+0

dev가 svn을 사용하여 백업하는 경우, 코드를 너무 오래 붙잡고있는 것일 수 있습니다. 작업 속도로 인한 것이라면 정말 즐거운 해결책은 아닙니다. 너무 커밋 된 커밋 때문인 경우에는 대개이를 수정할 수 있습니다. 편의와 레포 청결 중에서 선택해야 할 수도 있습니다. 예를 들어 개발자가 무언가로 완료 한 길의 1/4 만 있지만 금요일에는 5 일 경우 워크 스테이션의 데이터 안정성에 문제가있는 경우 커밋 측면에서 힘든 선택이됩니다. – Corbin

1

일상 업무가 필요하지 않아도됩니다. 모든 사람들이 기본 소스 디렉토리의 파일들에 대해 작업하도록하십시오. 코드를 하위 디렉토리 (예 : "/ trunk")로 이동하면 루트에 다른 디렉토리 (예 : 브랜치 디렉토리)를 가질 수 있습니다.

개발할 때 충돌이 발생하지만 작고 쉽게 해결되어야합니다. 커밋은 가능한 한 작아야합니다. TortoiseSVN은 커밋 할 때 충돌을 해결하기위한 훌륭한 사용자 인터페이스를 제공합니다.

이어야합니다. 두 개 이상의 개발자가 트렁크에 커밋 할 수없는 기능에 함께 작업하는 경우입니다 (예 : 다음 릴리스에서 출시 준비가되어 있지 않고 예정되어있는 경우). 최신 릴리스.

분기를 만들려면 응용 프로그램을 릴리스해야합니다.첫 번째 릴리스에 1.X라는 분기를 만듭니다. 그런 다음 트렁크에서 2.0을 향해 계속 작업하십시오. 1.X 지점에서는 1.0 릴리스를 구축 할 수 있으며 나중에 1.1 릴리스를 구축 할 수도 있습니다 (트렁크 2.0 작업을 방해하지 않고).

이 두 가지 유형의 차이점에 유의하십시오. 릴리스 분기는 트렁크에서 분기되어 영원히 살아납니다. 개별 버그 수정은 트렁크와 릴리스 분기간에 병합 될 수 있지만 릴리스 분기는 트렁크에 다시 병합되지 않습니다.

기능 분기에서 트렁크 변경 사항은 병합을 통해 계속 가져옵니다. 기능이 완료되면 전체 브랜치가 트렁크에 병합되고 브랜치는 사용되지 않습니다. 매일 매일의 개발을위한

Release branches   __testing_1.X__..._rel_1.0___.._rel_1.1 ___2.X_branch_ 
         /          /
___________trunk__________/_______trunk______________________________/____.. 
     \            /
     \_____really big feature for v2 only__________/ 

Feature branches 

당신 할 수있는 당신이 원하는만큼 분기 사용. 한 가지 옵션은 기능 하나당 하나의 옵션이지만, 작은 팀에서 해결하는 것보다 더 많은 문제를 야기 할 수 있습니다. SVN에서 충돌을 해결하는 것은 일반적으로 여러 지점을 관리하고 많은 병합을 수행하는 것보다 훨씬 쉽습니다. 다른 버전 제어 시스템 (예 : 힘내)에서는 상황이 다릅니다.

관련 문제