매우 큰 오버 랩핑 코드 기반을 가진 여러 프로젝트가 있습니다. 우리는 방금 SVN을 사용하기 시작 했으므로 어떻게 사용해야하는지 알아 내려고합니다.여러 프로젝트에서 버전 제어를위한 모범 사례
문제는 내가 한 프로젝트에서 작업을 끝내면서 다른 작업을 시작하고 일부 겹치는 것입니다. 종종 인터럽트 구동 개발도 많이 있습니다. 그래서, 제 코드는 실제로 안정적인 상태에 있지 않습니다.
그 결과 우리는 VC 시스템을 사용하지 않고 있습니다. 이것은 매우 나쁜 것이고, 우리 모두는 알고 있습니다. 그래서, 제안?
코드의 개인 분기를 확인하고 변경 사항을 병합합니다. 적어도 롤백해야 할 경우에 대비하여 사용자 자신의 변경 사항에 대한 버전 제어 기능이 제공됩니다. 브랜치가있는 상태에 익숙해지면 해당 브랜치를 트렁크에 다시 병합하십시오.
각 개인에 대한 분기 대신 각 분기의 분기를 체크 아웃 할 수도 있습니다. 누군가가 트렁크를 변경하고 지점에 변경 내용을 반영하려는 경우 트렁크의 분기에 대한 변경 사항을 병합 할 수도 있습니다.
다른 워크 플로가 있지만 SVN을 사용하는 일반적인 방법입니다. 우리가 효과적으로 분기를 사용하지 않았기 때문에 커밋을 두려워했던 프로젝트에서 일했습니다 (아마도 빌드를 중단 할 것입니다).
브랜딩은 작업 흐름을 돕는 데 정말 강력합니다. 병합 아이디어에 익숙해 질 때까지 사용하십시오.
편집 : '분기 체크 아웃'은 분기 폴더에 분기를 생성 한 다음 해당 분기를 체크 아웃하는 것을 의미합니다. 표준 svn 저장소 구조는 루트에있는 트렁크, 태그 및 분기 폴더로 구성됩니다.
TFS에서는 'Shelf Sets'를 만들 수 있습니다 (다른 소스 제어 공급자에서 무엇이 호출 될지 모르겠습니다). 일부 코드를 제거하면 저장소에 저장되지만 체크인하지는 않습니다.
버그가있는 이유는 버그 XXXX를 사용하여 코드의 절반을 수정했지만 그렇지 않은 경우입니다. 안정적이고 '체크인 가능'하지는 않지만 NewFeature YYYY에 배정되면 동일한 코드 기반으로 계속 작업해서는 안됩니다. 버그 XXXX 코드를 '선반에 올려 놓은'다음 로컬 코드베이스를 최신 체크인 코드로 되돌리고 NewFeature YYYY를 구현하십시오.
이렇게하면 체크인을 원자 적으로 유지할 수 있습니다. 리포지토리에 보관되어 있기 때문에 작업 내용을 잃어 버릴 염려가 없습니다 (따라서 컴퓨터가 화염에 빠지면 눈물을 흘릴 필요가 없습니다). 그리고 XXXX에 대한 수정 사항을 혼합하지 않습니다. YYYY에 대한 새 코드를 추가하십시오. 그런 다음 YYYY를 체크인했다고 가정하면 XXXX로 돌아 가라는 요청을 받으면 '선반 세트 (shelf set)'의 선택을 취소하고 다시 시작한 지점으로 바로 돌아갈 수 있습니다.
SVN의 코드가 완전히 안정된 상태가 아니며 어쨌든 코드를 확인하십시오 (코드가 너무 많이 손상되지 않도록 모든 X 일/주마다 리팩토링 및 안정화를위한 시간을 예약하십시오).
또는 팀이 최소한의 중단 기반 개발로 구조화 된 방식으로 작업하도록하여 좋은 코드를 체크인 할 수 있습니다.
첫 번째 옵션은 이상적이지는 않지만 소스 컨트롤이 좋지 않은 경우 두 번째 옵션은 불가능합니다. 세 번째 옵션은 없습니다.
코드를 안정된 상태로 만들 시간이 없다면 항상 분지하고 병합 할 시간이 없어야합니다.
그래서, 내 코드는 내가 체크인 편안 완전히 안정된 상태에서 정말 결코 없다.
이 왜입니까?
예를 들어 좋은 명명 규칙을 사용하여 지사가 작업에 적합하면 모든 사람이 HEAD가 항상 안정적이지는 않다는 것을 알게됩니다.
이런 종류의 "working"브랜치에서 몇 가지 "안정된 코드 포인트"(어떤 테스터가 배치 될지를 질의 할 수 있음)를 나타내는 태그를 넣으면됩니다.
현재 상태가 안정적이지 않더라도 해당 작업 분기의 다른 버전은 변경 내용을 기록하기 위해 만들어졌습니다.
그런 다음 안정 상태를 나타내는 것으로 간주되는 분기에 모두 병합합니다.
GIT와 같은 분산 소스 제어 시스템에서 로컬 저장소에 커밋합니다. 코드를 푸시 할 때만 원격 저장소에 '완결'됩니다.
이렇게하면 훨씬 더 쉽게 작업 할 수 있습니다.
문제는 우리가 7 명의 엔지니어 (2 엔지니어)이기 때문에 구조화 될 여력이 없다는 것입니다. 또한 "팀"은 저뿐입니다. –