버전 관리 방식에 문제가 있습니까?

비즈니스 분석가로 프로그래머 팀과 함께 작업합니다. 우리는 방금 제품의 버전 2.0을 출시했으며 3 개월 안에 출시 될 다음 버전 (내부 소프트웨어 제품)을 위해 노력하고 있습니다. 불행히도 버전 2.0에는 수정해야 할 몇 가지 문제가 있으며 몇 주 안에 해당 수정 사항을 배포 할 예정입니다. 문제는 아직 진행 중이며 향후 3 개월 동안 릴리스되지 않는 변경 사항을 배포하고 싶지 않다는 것입니다.

프로그래머는이를 관리하는 방법은 결함 코드 만 체크인하고 새로운 기능 향상을위한 코드는 개발자의 로컬 컴퓨터에 완료 될 때까지 유지하는 것이라고 결정했습니다. 코드를 체크인하고 결함을 수정하기 위해 다른 패치를 배포해야하는 경우에는 아직 개선 사항을 포함하고 싶지 않기 때문에 테스트를 위해 컴퓨터에서 로컬 빌드를 가져와야합니다. 동일한 코드 파일에 결함 수정 및 개선 사항이 모두 포함되어있어 코드 파일을 로컬로 복사 한 다음 버그를 수정하여 버그를 확인한 다음 수정하여 수정 작업을 다시 시작해야하는 문제도 있습니다. 그들이 만든 현지 사본.

상당히 복잡한 것처럼 보입니다-이러한 유형의 시나리오를 처리하는 더 좋은 방법이 있습니까? 우리는 Team Foundation Server와 Visual Studio 2010을 사용하고 있습니다.

V2.0은 우리가 사용했던 '안정 상태 브랜치'(TFS가 아닌 Perforce를 사용)를 출시했을 때 사용했습니다. v2의 모든 수정 사항은이 분기에 적용된 후 v3 기능도 작업하는 동안 v3 개발 분기로 다시 전파되었습니다. 즉 v2의 결함으로 인해 v3에도 결함이 발생합니다.

개발자 시스템에 오랫동안 변경 사항이 있으면 통합 악몽이 발생할 수 있습니다.

이와 같은 문제를 처리 하는 방법 에는 여러 가지 가 있으며 , 일반적으로 각각의 장점과 단점이있는 'branching'태그로 덮여 있습니다.

그러나 개발자가 선택한 접근 방식 ... gee 내가 잘못 읽지 않도록 구두로 인용합니다 ...

코드 ... 개발자의 로컬 컴퓨터에 완료 될 때까지 유지됩니다 ...

... 위와 같은 방법은 아마도 완전히, 완전히 잘못된 유일한 방법 일 것입니다!

TFS의 경우, 뛰어난 이해하기 쉬운 Microsoft Team Foundation Server Branching Guidance- 모든 종류의 다양한 프로젝트에 맞게 신중하게 조정 및 설명 된 분기 전략 권장 사항이 포함 된 크고 자세한 문서가 있습니다 ( HTML 버전). 여기 ).

1. 개발자는 버전 제어를 사용하는 방법에 대한 근본적인 오해가 있습니다.
2. "올바른"버전 제어 소프트웨어에 대해 논의하지 마십시오. 이것은 문제가 아닙니다.
3. 모든 코드 조정은 문제를 해결하기 어렵게 만듭니다.
4. 모두가 옳은 일을하기로 결정하면 문제를 해결하는 동안 코드 변경을 계속할 수 없습니다. 모든 개발을 중단하고 코드를 버전 관리로 가져와야합니다.
5. 개발자 는 적어도 앉아서 그것에 대해 이야기하기에 충분한 고통을 느끼고 있어야 합니다.
6. 모든 버전 제어 소프트웨어는 기본 개념을 지원합니다.
   • 모든 코드는 버전 관리 저장소에 들어갑니다.
   • 모든 코드 파일에는 버전 번호가 있습니다. 이 번호는 코드가 다시 체크인 될 때 ​​자동으로 증가합니다.
   • TAG는 특정 버전의 모든 코드 파일을 표시합니다. 따라서 소프트웨어 버전 1 릴리스에 태그를 지정할 수 있습니다.
   • BRANCH는 기본 트렁크 에서 "돌려"있습니다 .
     • 분기에 대한 모든 변경 사항은 트렁크에 영향을 미치지 않습니다.
     • 선택적으로 지점 변경 사항을 특정 시점에 기본 트렁크로 다시 병합 할 수 있습니다 .
     • 따라서 우리는 "좋은 것들"을 망칠 걱정없이 실험 할 수 있습니다.
7. 내가 부르는대로 버전 관리에 "신념의 도약"을 가져와야합니다. 기본 규칙을 준수하면 일이 똑바로 유지됩니다. 경험이 없으면 다르게 생각하고 나를 믿습니다.
8. 여기 괜찮은 튜토리얼이 있습니다. 다른 많은 소스를 our이 필요가 없을 정도로 일반적이며 완벽합니다.
   • 더 나은 버전 관리

편집하다

• 업무용 컴퓨터에 버전 관리 기능을 추가하십시오.
  • 팀 조정없이 바로 할 수 있습니다
  • 팀 버전 관리에도 불구하고 이것을 강력히 권장합니다
  • 팀에서 Git 또는 Mercurial을 사용하는 경우 독립적 인 로컬 저장소를 사용하는 것입니다. 이것이 분산 버전 관리의 작동 방식입니다.
  • 팀과 다른 VC 소프트웨어를 사용할 수 있습니다. 우리 팀은 Subversion을 사용하고 Mercurial을 로컬로 사용합니다. VC 소프트웨어 메타 파일 ( ".svn", ".mg", 숨겨진 폴더)은 충돌하지 않습니다.

사실상의 팀 저장소 역할을하지 않습니다. 팀이 코드베이스를 계속 FUBAR하는 동안 자신의 작업 관리, 리팩토링 노력 등을 CYAing하기위한 것입니다.

편집 종료

당신이 설명하는 것은 버전 제어를 사용하는 끔찍한 방법입니다. 릴리스 2.0에 대한 브랜치 또는 태그 또는 일부 식별자가 있어야합니다. 이렇게하면 해당 릴리스에 대한 수정 사항이 포함될 수 있으며 더 많은 개발이 계속 진행될 수 있습니다.

이 기사는 몇 가지 아이디어를 줄 수 있습니다. 그것은 git염두에두고 작성 되었지만 그것이 작동하지 않을 이유는 없습니다 mercurial. 나는 당신이 이것들 중 어느 것도 사용하지 않는다는 것을 알고 있지만, 그것은 또한 고쳐야 할 문제이기도합니다.

빠른 답변 : 개발 팀은 배포 된 코드 기반 V2.0을 기본 트렁크 와 분리하여 유지하기 위해 별도의 프로덕션 브랜치 를 보유해야 합니다.

코드를 동기화 상태로 유지 하려면 모든 버그 수정 을 해당 분기에서 먼저 수행 한 다음 테스트하고 다른 분기에 배포해야 합니다 .

프로젝트에는 Prod, Staging, QA 및 Dev (때로는 UAT) 와for health development 같은 여러 환경이 있어야합니다 . 이러한 환경은 프로덕션 릴리스로 이동 하기 전에 설정해야합니다 .

대체로 버그와 수정에 대비하는 것은 출시 된 응용 프로그램을 지원하는 방법입니다.

TFS가 버전 관리로 언급되었으므로 건강 개발 환경을 설정하는 데 도움이되는 기사 목록도 정리했습니다.

• 소규모 개발 팀과 함께 Team Foundation Server 구현
• TFS 통합 플랫폼에 오신 것을 환영합니다!
• TFS 가이드를 통한 팀 개발
• 개발 환경 설정

아니요. VCS를 사용하는 동안 버전 제어를 수행하지 않기 때문입니다.

버전 관리의 핵심 개념은 시간에 따른 차이를 추적하는 것입니다. 몇 가지 차이점을 기록 할 계획이지만 현재 대부분의 변경 사항은 기록되지 않습니다.

다른 사람들이 말했듯이 분기를 사용해야합니다. 해당 설정이 완료되면 모든 기능 변경 사항을 확인해야합니다 (예 : 모든 키 입력이 아니라 버그를 수정하거나 기능을 추가하거나 기능을 삭제하거나 변경 사항을 완료하여 빌드 및 작동하는 경우).

저는 개발자이며 현재 버전의 수정 사항과 개선 사항 및 이후의 연속 버전에 대해 다른 분기 코드와 db가 제공됩니다.

수정이 완료되면 수정 사항이 프로덕션과 병합되고 배포되며 새로운 지점을 다시 개선 기능으로 다시 가져옵니다.

또한 현재 버전에 대한 10 가지 수정 사항이있는 경우와 같은 방법을 따릅니다.

나는 다음과 같이 쓴다

//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"

다른 수정 프로그램과 마찬가지로 수정하거나 수정하기 위해 추가하는 모든 줄 마다이 작업을 수행합니다. 그리고 비교하고 커밋하십시오. 마찬가지로 동일한 지점에서 병렬 작업을 수행하는 경우 사용할 수 있습니다

//Start Enhancement -1, Branch No-"ABC" 
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC" 

Ctrl+Shift+F//Start Iteration 2, Fix No-1, Branch No-"ABC" 전체 솔루션에서 검색하는 명령 및 유형 을 사용하면 정확한 위치, 코드가 변경된 파일 및 해당 부분 만 새 코드를 사용하여 커밋하는 데 도움이됩니다.