답변:
빈번한 커밋을 장려하십시오. 버전 관리를 처음 접하는 팀원은 "올바르게 작동"할 때까지 코드를 저장소에 보관해야한다고 생각할 수 있습니다. 모든 사람에게 가능한 한 빨리 문제를 발견하도록 일찍 그리고 자주 수행하도록 가르치십시오. 코드가 작동 할 때까지 유지하는 대신 팀원이 트렁크를 깨뜨릴 수있는 기능에 대한 분기를 생성하도록 제안하십시오. 그게 ...
분기 및 태깅 관행을 확립하십시오. 기능에 대한 분기 외에도 팀원이 큰 버그 수정을 위해 분기를 사용하도록 권장하십시오. 작업 시작과 끝에 주요 버그 수정에 태그를 지정합니다. 프로덕션 / QA 릴리스에 대한 태그 (및 가능한 분기)를 유지합니다.
트렁크에 대한 정책을 수립하고 고수하십시오. 한 가지 예는 "트렁크는 항상 오류없이 빌드되어야합니다."입니다. 또는 "트렁크는 항상 모든 단위 테스트를 통과해야합니다". 아직 트렁크 기준에 맞지 않는 작업은 반드시 지점에서해야합니다.
코드 변경으로 서식 변경을 커밋하지 마십시오.
거대한 파일의 공백 ( Control+ K+ D) 을 재구성하려면 괜찮습니다. 실제 논리적 변경과 별도로 서식 변경을 커밋합니다. 파일에서 함수를 이동하려는 경우에도 마찬가지입니다. 실제 편집과는 별도로 이동을 커밋하십시오.
내가 항상 고수하는 핵심 개념 중 하나는 관련 코드 변경 사항을 함께 커밋하는 것 입니다. 결과적으로 동일한 커밋에서 관련없는 코드 변경 사항을 커밋하지 않습니다 . 즉, 하나의 커밋에서 2 개의 버그를 수정하지 말고 (동일한 수정 사항이 아닌 경우) 2 개의 커밋 각각에서 절반의 버그 수정을 커밋하지 마십시오. 또한 시스템의 관련없는 부분에 새로운 개선 사항을 추가하거나 다른 작업에 필요한 사항을 추가해야하는 경우 개선 사항을 별도로 커밋합니다. 아이디어는 누구나 자체적으로 (또는 자체적으로 롤백하기) 원하는 변경 사항은 별도의 커밋이어야한다는 것입니다. 병합을 수행하거나 손상된 기능을 롤백 할 때 많은 골칫거리를 절약 할 수 있습니다.
이미 많이 언급되었으며 여기에 몇 가지 더 있습니다.
소스 제어에서 원하지 않는 파일 (예 : 구성, 컴파일 된 파일 등)이있는 경우 무시 목록에 추가합니다 . 이렇게하면 항상 SVN에 알려지지 않은 것으로 표시되는 빈 파일 목록을 예상하여 추가하지 않은 파일을 발견 할 수 있습니다.
커밋 된 변경 사항 및 이상적으로는 패치와 관련 하여 개발자 메일 링 목록 (또는이 대상에 대한 특정 항목)에 이메일을 보내는 커밋 후 이벤트를 추가 합니다.
버그 추적기와 통합 하여 커밋에 대한 참조가 차이점에 대한 링크와 함께 버그 / 기능 요청에 표시되도록합니다. MantisBT 와 같은 버그 추적기가 이를 지원합니다.
지속적인 통합 (예 : CruiseControl.NET ), 빌드 용 NAnt 및 단위 테스트 용 NUnit / VS 와의 통합을 고려하십시오 . 이렇게하면 사용자가 코드를 체크인하거나 예약 된 간격에 따라 코드가 컴파일되고 단위 테스트가 실행되고 개발자는 프로세스에 대한 피드백을받습니다. 이것은 또한 저장소가 고장난 경우 (즉, 빌드하지 않는 경우) 나머지 팀에게 경고합니다.
글쎄, 기본 :
사람들이주는 대답은 훌륭합니다. 이것의 대부분은 SVN의 모범 사례에 대한 svn 사용자 문서에 요약되어 있습니다.
반복하려면 :
내가 고수하는 모범 사례를 요약하고 싶습니다.
저장소 구조 가 있어야합니다 . 개인적으로 다음 저장소 구조를 사용합니다.
/trunk
/tags
/builds
/PA
/A
/B
/releases
/AR
/BR
/RC
/ST
/branches
/experimental
/maintenance
/versions
/platforms
/releases
PA(사전 알파), A(알파), B(베타), AR(알파 출시), BR(베타 출시), RC(출시 후보), ST(안정).내가 사용하는 소프트웨어 구성 관리 접근 방식의 주요 원칙을 보여주는 다이어그램 형태로 Subversion 모범 사례의 개요를 찾을 수 있습니다 .
내가 매우 유용하다고 생각한 한 가지는 svn : external 속성으로, 다른 저장소의 디렉터리를 자신의 것으로 참조 할 수 있음을 의미합니다. 코드와 데이터를 구성하는 정말 좋은 방법을 제공합니다. 몇 가지 예는 다음과 같습니다.
버그 추적 소프트웨어와의 통합을 사용하십시오. Bugzilla 를 사용하는 경우 댓글이 "Bug XXXX"로 시작하면 SVN 댓글이 해당 수정 버전에 대한 SVN 웹 인터페이스에 대한 링크를 포함하여 주어진 버그에 대한 댓글로 자동 추가되도록 설정할 수 있습니다.
SVN의 분기 및 병합 도구와 규칙에 대해 알아보십시오.
다른 팀 구성원과 함께 작업하는 가장 좋은 방법은 작업을 완전한 개발 기능 / 수정으로 분할 한 다음 브랜치에서 개별 변경 작업을 수행하는 것입니다. 그런 다음 병합이 완료 / 준비 / 승인되면 변경 사항을 다시 메인 라인 분기 / 트렁크에 병합합니다.
이러한 방식으로 개인은 다른 변경 사항과 충돌하지 않고 공통 목표 (동일한 분기 또는 별도의 분기)를 향해 작업 할 수 있습니다.
귀하의 마일리지는 다를 수 있으며 이는 2 명 정도의 과잉 일 수 있습니다.
SVN과 잘 통합되는 좋은 도구를 사용하면 훨씬 더 쉬워집니다. 이를 통해 변경된 사항을 쉽게 확인한 다음 변경 사항의 전부 또는 일부를 커밋하고 작업 복사본을 SVN의 최신 버전으로 자주 업데이트 할 수 있습니다.
Tortoise SVN (Windows를 사용하는 경우)과 Visual SVN (VS를 사용하는 경우 )을 권장 합니다.
또한 변경 사항이 커밋 될 때마다 이메일 또는 유사한 알림을 받도록 설정할 수 있는지 확인하십시오 (일반적으로 커밋 메시지 및 변경된 파일 목록 포함). CVSDude 와 같은 서비스가 이를 제공합니다. 업데이트가 이루어 졌음을 알고 작업 복사본을 업데이트하기 전에 해당 업데이트에 포함 된 내용을 파악하는 것이 도움이됩니다.
분기 정책 외. (하나의 크기가 모든 것에 맞지 않는 경우), 좋은 커밋이 있어야합니다.
소스 제어의 황금률 : 조기 체크인, 자주 체크인
저장소를 구성하는 방법에 대한 팁 :
변경 사항에 대해 팀과상의하거나 병합 충돌을 수정하기 전에 적어도 차이점을주의 깊게 살펴보십시오. 병합에서 추가 한 내용이 손실되지 않았는지 확인하기 위해 병합 된 코드를 직접 검토하도록 요청합니다.
깨진 커밋을 줄이는 한 가지는 좋은 사전 커밋 스크립트를 사용하는 것입니다. 예를 들어 변경 사항이 커밋되기 전에 모든 단위 테스트를 실행할 수 있습니다. 이로 인해 커밋이 약간 느려질 수 있지만 누군가의 발끝을 밟고 사과하지 않아도되므로 시간을 절약 할 수 있습니다. 물론 대규모 개발 팀이 있고 커밋이 매우 빈번하면 관리하기가 훨씬 더 어려워집니다.
SVN 사용 모범 사례 :
사무실에 처음 와서 Eclipse 프로젝트를 열었을 때 수행해야 할 첫 번째 단계는 프로젝트를 업데이트하는 것입니다.
업데이트 후 작업을 시작하십시오. 코딩을 마쳤 으면 애플리케이션이 예외없이 제대로 실행되는지 제대로 확인하십시오. 코드가 제대로 작동하고 있다고 확신하면 코드를 커밋해야합니다.
참고 : 코드를 커밋하는 동안 직접 커밋하지 마십시오. 서버와 동기화하고 커밋해야 할 모든 것이 무엇인지 확인하십시오. 참고 : 전체 폴더를 한 번만 커밋하지 마십시오. 요구 사항에 따라 파일을 일부 변경했거나 로컬 시스템에서 일부 파일을 삭제했을 수 있기 때문입니다. 그러나 설정은 서버에서 다릅니다. 따라서 파일을 개별적으로 확인하고 코드를 커밋하십시오.
충돌 파일을 직접 커밋 / 업데이트하지 마십시오.
재정의 및 업데이트는 언제 수행합니까?
로컬 변경이 필요하지 않고 서버 사본을 완전히 업데이트하고 싶을 때. 재정의 및 업데이트를 한 번 수행하면 로컬 변경 사항이 적용되지 않습니다.
참고 : 업데이트없이 하루 이상 프로젝트를 보관하지 마십시오. 또한 며칠 동안 커밋하지 않고 코드를 보관하지 마십시오.
누가 모두 동일한 구성 요소에서 작업하고 있는지 소통하고 매일 변경 한 사항에 대해 논의합니다.
이유가없는 한 속성 및 구성 파일을 커밋하지 마십시오. 서버와 클라우드에서 설정이 다르기 때문입니다.
대상 폴더를 SVN에 커밋하지 마십시오. 소스 코드와 리소스 폴더 만 SVN 저장소에서 유지 관리하면됩니다.
코드를 잃어 버렸을 때 당황하지 마십시오! SVN 기록에서 이전 사본을 다시 가져올 수 있습니다.
프로젝트를 디스크의 여러 위치로 체크 아웃하지 마십시오. 한 곳에서 확인하고 작업하십시오.
SVN 자체는 좋은 시작이며 다른 포스터 중 일부는 모범 사례에 대한 훌륭한 제안을 제공했습니다.
내가 추가 할 유일한 것은 SVN을 CruiseControl 또는 TeamCity와 연결하여 지속적인 통합 프로세스를 추진해야한다는 것입니다. 이렇게하면 빌드 이메일이 발송되고 누군가 빌드를 망가 뜨렸을 때 모든 사람에게 알립니다.
누가 당신의 프로세스를 따르고 있는지, 누가 그렇지 않은지 일찍부터 알려줄 것입니다. 약간의 마찰로 이어질 수 있지만 팀은 장기적으로 더 나아질 것입니다.
점진적, 모듈 식, 이산 적이며 간결하게 커밋할수록 사용자 (또는 다른 사람들)가 다음 작업을 더 쉽게 수행 할 수 있습니다.