커밋을 올바르게 관리하고 기능 충돌을 방지하며 VCS와의 종속성을 어떻게 관리 할 수 ​​있습니까?

대규모 팀과 함께 일하면서 성가신 요소가되었습니다. 체크인을 관리하고 기능 충돌을 방지하고 소스 제어와의 종속성을 어떻게 관리합니까?

현재 직장에서는 TFS 2008을 사용하고 있으며 12 월 초에 TFS 2010으로 마이그레이션하고 있습니다. 첫째, 모든 소스 제어가 낫지 않는 것보다 낫지 만 소스 제어 기록 전체에서 다중 체크인 및 롤백을 방지하는 데 유용한 방법은 무엇입니까? 휘발성 트렁크는 새로운 기능을 구현할 때 그리고 트렁크에 다시 합쳐지는 가장 좋은 방법입니까?

다른 사람들의 경험과 아마도 소스 제어 관리에 대한 모범 사례를 듣고 싶습니다.

TFS? 언덕을 향해 달려라! 최대한 빨리 출발하십시오. 그것은 많은 다른 일을하지만 사용 가능한 최고의 품종 도구만큼 좋은 것은 없습니다.

그러나 진지하게 :

적절한 버전 제어 시스템 (SVN, GIT 등)을 확보 한 후에는 브랜치 생성시기, 분기, 병합시기, 병합시기, 대상 등을위한 분기 관리 규칙을 설정하는 것이 좋습니다.

최근까지 우리는 새로운 개발 ( '트렁크')에 단일 브랜치를 사용했습니다. 릴리스의 경우 브랜치 오프 트렁크를 만듭니다. 최종 QA는 해당 지점에서 수행되며 완료되면 릴리스합니다 (매월 릴리스).

스케줄 위험을 줄이기 위해 '트렁크에 정크 없음'이라는 개념으로 전환했습니다. 이 개념에는 기본적으로 트렁크와 별개로 개발 작업을위한 분기를 작성하는 규칙이 포함되어 있습니다. 예를 들어, 소규모 개발 팀 등을 위해 기능에 대해 별도의 지점을 가질 수 있습니다. '소설'을 사용하여 작은 지형지 물 또는 지형지 물의 릴리스 가능한 부분을 설명하고 각 서사시의 분기를 만듭니다. 최소한 하루에 한 번 트렁크의 모든 변경 사항이 서사시 지점으로 병합됩니다. 키는 버전 제어 또는 별도의 도구 (예 : 3 방향 병합)에 의한 병합 지원이 우수합니다. 서사시의 QA는 서사시 지점에서 수행됩니다. 일단 에픽 브랜치를 통과하면 트렁크로 병합되고 통합 테스트가 실행됩니다. 우리는 여전히 릴리스를위한 브랜치를 가지고 있습니다.

서사시 지사를 통해 우리는 이제 트렁크에서 릴리스 할 위치에 있고 스케줄에 성공적으로 병합 된 모든 서사시를 포함함에 따라 일정 위험을 크게 줄였습니다. 완전하지 않은 서사시 버스를 그리워하고 다음 릴리스 (다음 달)를합니다.

이것은 물론 우리 환경에서만 작동 할 수 있습니다. 지점 관리를위한 최상의 선택에 영향을 미치는 요소와 다른 요소가있을 가능성이 큽니다.

예를 들어 많은 사람들이 원격으로 작업하고 항상 버전 제어 서버에 연결되어 있지 않은 팀이있는 경우 분산 모델을 지원하는 버전 제어 시스템을 사용하려고합니다. GIT와 다른 몇 사람이이 범주에 속합니다. 내가 아는 한 TFS는 파일을 쓰기 가능하게 만들기 위해 서버에 연결해야합니다 (버전 2010에서 수정 되었습니까?).

나는 "하나의 크기가 모두 맞지 않는다"는 것을 보여줄 수 있었으면 좋겠다. 특정 지점 관리의 프로세스부터 시작하여 요구 사항을 결정한 후 마지막으로 요구 사항에 가장 적합한 도구를 선택하십시오. 아마도 TFS 일 수도 있고 아닐 수도 있습니다.

배송 할 기능과 연기 할 기능을 결정할 때 뛰어난 유연성을 제공하므로 기능 당 하나의 브랜치를 옹호합니다.

귀하의 상황에서 얼마나 잘 작동하는지는 VCS가 브랜치를 얼마나 잘 처리하고 더 중요한 병합을 수행하는지에 달려 있습니다. Git & Mercurial과 같은 DVCS는 이것을 비교적 사소한 운동으로 만듭니다. SVN이 적습니다. 나는 그것에 대해 많은 것을 읽었지만 TFS를 피할 수있었습니다. 주로 비 보완 적입니다. TFS에 갇힌 경우 지점 당 하나의 기능을 기반으로 소규모 파일럿 릴리스를 수행하고 병합이 얼마나 잘 수행되는지 확인하십시오.

첫째, 면책. 우리는 매일 팀을 운영하는 방법을 알지 못하므로 소스를 관리하는 가장 좋은 방법을 말하기는 어렵습니다.

일반적으로 트렁크에서 작업하는 것이 좋습니다. 각 주요 릴리스에 대해 분기-릴리스 버전에 대한 버그 수정이 분기에 있으며 다시 트렁크로 병합 될 수 있습니다. 모든 개발자는 트렁크에서 작업하고 코드를 정기적으로 작성합니다 (최소한 하루에 한 번).

새로운 코드를 정기적으로 병합하면 대규모 통합 단계에서 많은 양의 코드를 병합하는 데 따르는 어려움이 최소화됩니다. 고통을 퍼 뜨리면 덜 느끼게됩니다. 팀원이 코드를 커밋하는 빈도가 높을수록 병합 시간이 줄어 듭니다. 항상 최신 소스에 있기 때문입니다.

나는 TFS 2008/2010을 사용한 적이 없지만 다양한 포럼에서 읽은 내용에서 버전 제어에 TFS를 사용하는 것에 대해 많은 부정이 있습니다. 이것은 지금까지 TFS로부터 명확하게 유지되었습니다.

나는 현재 SVN과 Git을 사용하고 있으며, 소규모 팀이나 싱글 맨 팀 모두에게 좋지만 큰 팀에게는 SVN을 개인적으로 권장하지 않습니다.

나는 PlasticSCM을 주시하고 있으며 가까운 시일 내에 시도 할 것입니다.

귀하의 특정 질문에 답변하지 않은 것에 대해 사과 드리며, 특권이 허락 한 경우 의견을 게시했을 것입니다.

git은 다른 모든 소스 제어 소프트웨어를 쓸모 없게 만든다고 생각합니다. 분기 및 병합은 쉬우 며 문제가있는 경우 포함되지만 매우 빈번한 커밋, 분기 및 병합을 장려하는 방법으로 많은 문제를 피할 수 있습니다. 각 사용자는 저장소의 전체 사본을 얻습니다 (이 내용은 정리 할 수는 있지만 꽤 큰 코드베이스로 작업하고 문제는 아닙니다). 자동 백업이 있습니다. 커밋 / 푸시 / 풀은 빠르며 가장 중요한 것은 파일 이름과 추적 간의 연결을 끊는 것입니다. 이름과 경로를 포함한 파일 데이터는 경로와 무관 한 트리 노드에서 참조하는 데이터 블로 브입니다. 이것은 더 안전 할뿐만 아니라 SVN과 같은 특정 종류의 "하지 마십시오"문제는 문제가되지 않습니다. 기존 허브 구성 또는 피어 투 피어로 사용할 수 있으며 이러한 설정은 동일한 설정에서 자유롭게 혼합 할 수 있습니다. 문서화되지 않은 삽입에 대해 암호로 안전합니다. 그리고 그것은 매우 빠릅니다.

파일을 서버에 백업하거나 저장하는 것보다 파일 서버에 커밋하고 푸시하는 것이 더 쉽기 때문에 문서를 추적하고 컴퓨터간에 동기화하기 위해 항상 집에서 항상 사용하는 것으로 나타났습니다.

단점은 사람들이 소스 제어에 익숙한 모든 규칙을 미묘한 방식으로 짧지 만 가파른 학습 곡선을 위반하기 때문에 약간 가파른 학습 곡선입니다.

우리가 실제로 따르고 많은 도움을 준 몇 가지 모범 사례 :

1) 로컬에 파일의 쓰기 가능한 사본이 없는지 확인하고 항상 편집을 체크 아웃하십시오. (경우에 따라 로컬에서 작업해야하는 경우 EOD 전에 소스 제어에 병합하십시오.)

2) 중요한 중요 시점 이후에 파일에 정기적으로 레이블을 지정하십시오.

3) 좋은 체크 아웃 또는 체크인 주석을 제공하십시오. 검토 할 때 도움이되며 때로는 버전을 열고 비교할 필요가 없습니다.

체크인을 관리하고 기능 충돌을 방지하고 소스 제어와의 종속성을 올바르게 관리하는 방법은 무엇입니까?

그것은 내 POV에서 두 가지 요소 작업입니다. 기술 (좋은 & 쉬운 & 방탄 분기 병합 등) 및 관리 (잘 확립 된 정책 "무엇" "어떻게" "어떻게") 측면에서해야합니다. ALM에서 두 개 또는 세 개의 분리 코드 계층 : "안정한"(통과 된 단위 테스트), "불안정한"(포함 된 기능이 모두 포함되어 있지만 제품으로 통합 된 질문이있는 앱은 / yes, / 가 발생할 수 있음 ) 및 " 진행중인 작업". 이런 식으로 적절한 프로젝트 관리자는 개별 개발자의 작업에 대한 공통적 인 간섭을 줄일 수 있습니다.

TFS (사용하지 않고 사용하고 사용하지 않을 것)에는 AFAIK라는 몇 가지 근본적인 문제가 소스 제어 관리 측면에서 있습니다. 제임스 맥케이 (James McKay)의 일부 텍스트에 연결합니다.

• Team Foundation Server는 Lotus Notes 버전 관리 도구입니다.
• Team Foundation 서버에서 기본없는 병합 – 왜?

소스 제어 작업의 몇 가지 다른 방법을 명확하고 간결하게 비교하고 대조하는 정말 훌륭하고 최근의 기사가 여기 있습니다 : Source Control Done Right .

나는 어떤 생각하지 않는 하나 개의 소스 컨트롤을 사용하기위한 전략 / 베스트 프랙티스가. 오랫동안 함께 일해온 성숙한 팀은 인기있는 "모범 사례"를 정확하게 따르지 않더라도이 분야에서 "고통"이 훨씬 적습니다.

어떤 도구에 관해서는 ... 거의 중요하지 않습니다. 실제로 중요한 것은 팀의 모든 사람이 사용량과 동일한 페이지에 있도록하는 것입니다. 즉, 모든 사람이 코드 라인을 관리하는 방법과 예상되는 작업을 이해해야합니다. 어쨌든 실제로는 어떤 도구를 사용할지 선택하지 않아도됩니다. 사용중인 모든 것을 최대한 활용하십시오.