분기 또는 분기하지?

최근까지 개발 워크 플로는 다음과 같습니다.

1. 제품 소유자로부터 기능 가져 오기
2. 지점 만들기 (기능이 1 일 이상인 경우)
3. 지점에서 구현
4. 메인 브랜치에서 내 브랜치로 변경 사항 병합 (뒤로 병합하는 동안 충돌을 줄이기 위해)
5. 내 지점을 기본 지점으로 다시 병합

때로는 병합에 문제가 있었지만 일반적으로 마음에 들었습니다.

그러나 최근에는 지속적인 통합, 지속적인 전달 등을 수행하기가 더 어려워 지사를 만들지 않는 아이디어의 추종자들이 점점 더 많이 보았습니다. 분산 VCS 배경을 가진 사람들의 훌륭한 병합 구현에 대해 너무 많이 이야기 한 사람들에게는 특히 재미있게 들립니다. 힘내, 머큐리얼 등

문제는 요즘 지점을 사용해야합니까?

모두 동일한 작업 트리에서 작업하지 않는 한 호출 여부에 관계없이 분기 를 사용하고 있습니다. 개발자는 작업 트리에 체크 아웃 할 때마다 별도의 로컬 개발 분기를 작성하고 체크인 할 때마다 병합을 수행합니다. 대부분의 팀에서 분기를 사용하는 경우 질문은 아닙니다 . 질문은 몇 개 이며 어떤 목적 입니까?

진정으로 "연속적인"통합을 수행하는 유일한 방법은 모든 사람이 동일한 작업 트리에서 작업하는 것입니다. 이렇게하면 변경 사항이 다른 사람에게 부정적인 영향을 미치는지 즉시 알 수 있습니다. 분명히, 그것은 참을 수 없습니다. "브랜치"가 단지 로컬 작업 디렉토리 인 경우에도 무언가를 달성하려면 분기에서 어느 정도의 격리가 필요합니다. 필요한 것은 적절한 통합과 격리의 균형입니다.

필자의 경험에 따르면 더 많은 지점을 사용 하면 통합 수준이 향상됩니다 . 통합은 정확하게 수행해야하는 사람과 통합되므로 다른 모든 사람은 필요에 따라 비 관련 문제를보다 쉽게 ​​분리 할 수 ​​있기 때문입니다.

예를 들어, 나는 지난 날 빌드에서 "실제"작업을 차단하는 통합 관련 버그 3 개를 추적했습니다. 이 버그를 수정해야하는 사람들에게이 버그를보고하는 데 상당한주의를 기울 였다면 이제 작업을 계속할 때까지 기다려야합니까? 당연히 아니지. 이러한 변경 사항을 되 돌리는 임시 로컬 지점을 만들었으므로 업스트림에서 최신 변경 내용을 계속 수신하면서 안정적인 기준을 유지할 수 있습니다.

그 목적을 위해 새로운 지점을 만들 수 없다면, 중앙 저장소의 변경 사항을 되돌 리거나, 작업 트리에서 되 돌리는 패치를 수동으로 유지하고 실수로 체크인하지 않도록 시도하는 세 가지 옵션 중 하나로 줄어 듭니다. 버그가 도입되기 전에 버전으로 돌아갑니다. 첫 번째 옵션은 다른 종속성을 손상시킬 수 있습니다. 두 번째 옵션은 많은 작업이므로 대부분의 사람들은 세 번째 옵션을 선택하므로 이전에 발견 된 버그가 수정 될 때까지 더 많은 통합 작업을 수행 할 수 없습니다.

내 예제는 개인 로컬 브랜치를 사용했지만 동일한 원칙이 공유 브랜치에도 적용됩니다. 지점을 공유하면 중복 통합 작업을 수행하는 대신 5 명의 다른 사람이 기본 작업을 계속 수행 할 수 있으므로보다 유용한 통합 작업이 종합적으로 수행됩니다. 분기 및 지속적인 통합의 문제는 보유하고있는 분기 수가 아니라 분기를 병합하는 빈도입니다.

문제는 요즘 지점을 사용해야합니까?

약 반년 전에 나는 그 질문에 답하기 위해 연구를 수행하도록 지명되었습니다. 다음은 참고 문헌을 기반으로 한 요약입니다 (아래에 나열).

• 모든 프로젝트에 적용되는 일반적으로 합의 된 "최상의"분기 전략이 없습니다.
  • 대부분의 자원은 생산 전략 선택이 특정 프로젝트 특성에 달려 있음에 동의하는 것 같습니다
  • 사이드 노트. 위의 내용을 토대로 프로젝트 브랜칭 전략에 대한 변경 사항을 테스트, 측정 및 테스트 된 다른 옵션과 비교해야합니다.
• 대중적인 의견은 Subversion과 병합하는 데 많은 노력이 필요하다는 것입니다. SVN과 Git을 비교 한 모든 사람들은 Git을 사용하면 병합이 훨씬 쉽다는 점에 주목합니다.
• 중요한 요소는 생산 릴리스가 트렁크에서 시작되는지 아니면 분기에서 시작되는지입니다. 트렁크에서 프로드 릴리스를 수행하는 팀 (일반적으로 널리 사용되지 않는 것 같음)은 기본적으로 불안정한 트렁크 전략 을 사용하는 것이 금지됩니다 . 지점에서 제품 릴리스를 수행하는 팀은 더 많은 지점 옵션을 선택할 수 있습니다.
• 인기있는 전략은 안정적인 트렁크, 불안정한 트렁크 및 개발 (통합) 지점 인 것 같습니다

참조

• http://msdn.microsoft.com/en-us/library/aa730834%28v=vs.80%29.aspx
  

  ... 최고의 분기 전략을 결정하는 것은 균형을 잡는 행위입니다. 증가 된 위험과 생산성 향상의 균형을 유지해야합니다. 선택한 전략의 유효성을 검사하는 한 가지 방법은 변경 시나리오를 고려하는 것입니다. 예를 들어, 분기를 시스템 아키텍처 (예 : 분기가 시스템 구성 요소를 나타냄)와 맞추기로 결정하고 중대한 아키텍처 변경을 예상 할 경우, 각 변경과 함께 분기 및 관련 프로세스 및 정책을 재구성해야 할 수도 있습니다. 부적절한 브랜칭 전략을 선택하면 프로세스 오버 헤드와 긴 통합 및 릴리스주기가 발생하여 전체 팀에 실망감을 줄 수 있습니다.

• http://www.cmcrossroads.com/bradapp/acme/branching/
  

  ... 증분 통합은 성공의 징표 중 하나이며, 부재는 종종 실패의 특징입니다. 현재의 프로젝트 관리 방법은 엄격한 폭포수 모델을 피하고 나선형 / 유사 모델의 반복 / 증분 개발 및 진화 적 전달을 수용하는 경향이 있습니다. Merge Early 및 종종 변형 과 같은 증분 통합 전략 은 리스크에 대응할 시간이 더있을 때 라이프 사이클 초기에 리스크를 제거하려고하는 리스크 관리의 한 형태입니다. 통합 사이의 리듬의 규칙 성은 [Booch], [McCarthy] 및 [McConnell]에 의해 프로젝트 건강의 주요 지표로 나타납니다 ( "펄스"또는 "하트 비트"등).  
   
  조기 통합 및 빈번한 통합으로 인해 위험이 더 빨라지고 더 작은 "청크"가 발생할뿐만 아니라 팀원 간의 변화도 전달합니다 ...

• http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html
  

  ... 대부분의 소스 제어 시스템에서 성능 문제없이 수백 개의 분기를 만들 수 있습니다. 그것은 당신이 정말로 걱정해야 할 모든 가지를 추적 하는 정신적 오버 헤드 입니다 ... 분기는 복잡한 짐승입니다. 분기하는 방법에는 수십 가지가 있으며, 옳고 그름을하고 있는지 아무도 알 수 없습니다 ...

• http://www.lostechies.com/blogs/derickbailey/archive/2010/02/24/branching-strategies-when-to-branch-and-merge.aspx
  

  ... 코드를 분기 할 때 고려해야 할 시스템에는 여러 가지 측면이 있습니다 ... 결국 목표는 코드가 작성되는 컨텍스트에 샌드 박스를 제공하는 것입니다. 각 옵션이 현재 상황에 가장 적합한 경우 사용 가능한 옵션을 이해하고 이러한 옵션의 비용은 지점 및 방법을 결정하는 데 도움이됩니다.

• http://www.snuffybear.com/ucm_branch.htm
  여기에 나열된 다른 참고 자료를 고려할 때 저자는 "이 기사에서는 소프트웨어 엔지니어링 프로젝트에 사용 된 세 가지 주요 분기 모델에 대해 설명 합니다 "라는 주장을 정당화하지는 않습니다. 사용 된 용어는 널리 보급되지 않습니다 ( EFIX , Model-1,2,3 등).

• http://svn.haxx.se/users/archive-2007-10/att-0101/SCMBranchingModels-talkback.pdf
  참조는 분기 전략을 전달하는 데 어려움이있는 흥미로운 예를 제시합니다.

• http://simpleprogrammer.com/2010/06/04/simple-branching-strategy-part-1-back-to-basics/
  ... 간단히 유지하십시오. 트렁크에서 직접 작업하는 것이 지금까지 가장 좋은 방법입니다.  
   
  화면에 실제로 입력하면 거의 이단처럼 들리지만, 잠시 동안 나와 함께 견딜 수 있다면 이것이 왜 민첩한 프로세스에 필수적이라고 생각하는지 보여줄 것입니다. ...  
   
  이론을 하나의 확실한 논증에 근거해야한다면, 그것은 지속적인 통합의 가치가 될 것입니다. 과거 CI 의 가치 와 모범 사례 에 대해 블로그에 올렸 습니다. 나는 CI의 꽤 큰 지지자입니다 ...  
   
  ... 당신은 정말 여기에 자신에게 질문을해야한다 : "당신은 당신의 복잡한 분기를하고 더 간단한 전략을 통해 존재하지 않는 진정한 가치의 결과로 전략을 병합으로부터 초래되는 모든 오버 헤드가 있습니까?"...  
   
  .. 과거에 효과적으로 사용하고 시간이 지남에 따라 발전한 전략. 여기서 간단히 요약하겠습니다.

  • 모든 사람이 트렁크에서 일합니다.
  • 코드를 해제 할 때 분기합니다.
  • 이미 릴리스 된 코드에 대한 버그 수정을 작성해야하는 경우 릴리스를 분기하십시오.
  • 프로토 타입을위한 브랜치.
    ...
    • http://simpleprogrammer.com/2010/06/07/simple-branching-strategy-part-2-implementation/
      ... 꽤 자세한 연습 ...

• http://www.codelathe.com/blog/index.php/2009/07/02/a-svn-branching-strategy-that-works/
  ... 마지막으로 이상적인 분기 및 병합 전략이 없다는 것을 기억하십시오. 그것은 당신의 독특한 개발 환경에 달려 있습니다 ...

• http://blog.perforce.com/blog/?cat=62
  ... 가장 최악의 시나리오는 "병합 병합"문제가 발생하여 자동 병합의 결과가 정확하지 않지만 컴파일이 완료되고 과거에 몰래 지나간 것입니다. 고객이 볼 수있는 버그가 될 정도로 오래 지속될 수도 있습니다. 에크!  
   
  더 이상 탐지를 피할 수 있기 때문에 부상에 대한 모욕을 추가하면 시맨틱 병합 문제는 나중에 수정하기가 더 어렵습니다. 변경은 더 이상 변경을 만든 개발자의 마음에 들지 않기 때문입니다. (일반적으로 변경 사항을 작성한 개발자가 이상적으로 변경 사항을 병합하는 것이 가장 좋습니다.)

  • http://blog.perforce.com/blog/?p=1635
    참고 권장 정책 은 http://www.infoq.com/articles/agile-version-control#q11 및 http에 정의되어 있으므로 개발 지점 과 유사하게 나타납니다. : //msdn.microsoft.com/en-us/library/bb668955.aspx
  • 프로모션 모델 설명 : http://www.perforce.com/perforce/papers/life.html

• https://stackoverflow.com/questions/34975/branching-strategies
  커뮤니티 회원은 다양한 분기 전략을 사용하여 다양한 프로젝트에서 서로 다른 경험을 공유합니다. "최고"또는 "최악"에 대한 합의 된 합의가 없습니다.

  • http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
    "고전적인"읽기 - 같은 용어를 설명 본선 모델 , 코드 라인 등

• http://www.stickyminds.com/s.asp?F=S16454_COL_2
  기본적으로 http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf에 제시된 내용에 대한 간략한 요약

  • http://www.stickyminds.com/s.asp?F=S16511_COL_2
    ... 분기 시점과 방법을 결정하는 일반적인 세 ​​가지 접근 방식이 있습니다.
    • "기능 완료"일 때 릴리스 브랜치를 작성하고이 코드 라인의 최신 문제점을 수정하십시오. 이 경우 아직 수행 할 작업이있을 것으로 예상되므로 소프트웨어 구성 관리 패턴에 설명 된대로 릴리스 브랜치는 실제로 "릴리스 준비 코드 라인" 입니다.
    • 활성 개발 라인에서 작업하면서 최종 통합 작업을 피하기 위해 작업 스타일을 변경하십시오.
    • 릴리스가 완료된 후 작업 분기를 작성하고 해당 작업을 활성 개발 라인에 병합하여 새 작업의 분기.
      분기의 이론적 근거는 릴리스가 끝날 때 코드를 분리하여 코드를 안정화하는 것입니다. 분기를 통한 격리는 종종 제품이 출시되기 전에 병렬 스트림을 유지 관리하는 추가 비용으로 인해 품질 문제를 숨기는 경우가 많습니다. 분기가 쉽습니다. 그보다는 어려운 분기 간의 흐름이 어떻게 변화하는지 이해하는 것이 합병과인지 적 오버 헤드이므로 분기 및 합병 비용을 최소화하는 프로세스를 선택하는 것이 중요합니다.

• http://nvie.com/posts/a-successful-git-branching-model/ Git 지향 전략.
  ... 우리는 origin / master 를 HEAD의 소스 코드가 항상 프로덕션 준비 상태를 반영하는 주요 지점 이라고 생각 합니다 .  
   
  우리는 원산지 / 개발 을 HEAD의 소스 코드가 항상 다음 릴리스의 최신 개발 변경 사항이있는 상태를 반영하는 기본 지점으로 간주 합니다. 일부는 이것을 "통합 분기"라고 부릅니다. 이것은 자동 야간 빌드가 만들어지는 곳입니다 ....

  • http://www.infoq.com/articles/agile-version-control#q11 및 http://msdn.microsoft.com/en-us/library/bb668955.aspx에 정의 된 개발 브랜치 전략과 다소 유사 함

• http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html
  ... 프로젝트 정책은 기능 브랜치를 생성하는 것이 적절한시기에 따라 매우 다양합니다. 일부 프로젝트는 기능 분기를 전혀 사용하지 않습니다. / trunk 에 대한 커밋 은 무료입니다. 이 시스템의 장점은 간단하다는 것입니다. 아무도 분기 또는 병합에 대해 배울 필요가 없습니다. 단점은 트렁크 코드가 종종 불안정하거나 사용할 수 없다는 것입니다. 다른 프로젝트는 극단적으로 가지를 사용 변화가되어 지금까지 직접 트렁크에 최선을 다하고 없습니다. 가장 사소한 변경 사항도 단기 지점에서 생성되고 신중하게 검토 한 후 트렁크에 병합됩니다. 그런 다음 지점이 삭제됩니다. 이 시스템은 항상 안정적이고 사용 가능한 트렁크를 보장하지만 엄청난 비용이 소요됩니다프로세스 오버 헤드.  
   
  대부분의 프로젝트는 중간 정도의 접근 방식을 취합니다. 그들은 일반적으로 / trunk 가 항상 회귀 테스트를 컴파일하고 통과 한다고 주장합니다 . 기능 분기는 변경에 많은 수의 불안정화 커밋이 필요한 경우에만 필요합니다. 개발자가 분리에서 일 근무 후 (되도록 한 번에 큰 변화를 저지른 경우 : 엄지 손가락의 좋은 규칙이 질문을하는 것입니다 / 트렁크가 불안정 적이없는), 그것은 너무 큰 변화를 검토하는 것? 해당 질문에 대한 대답이 "예"이면 기능 분기에서 변경 사항을 개발해야합니다. 개발자가 지점에 대한 증분 변경 사항을 커밋하면 동료가 쉽게 검토 할 수 있습니다.  
   
  마지막으로 작업이 진행될 때 기능 분기를 트렁크와 "동기화"상태로 유지하는 방법에 대한 문제가 있습니다. 앞에서 언급했듯이 몇 주 또는 몇 달 동안 지점에서 일하는 데 큰 위험이 있습니다. 트렁크의 변경은 계속해서 진행될 수 있으며, 두 개발 라인이 크게 다른 지점으로 분기를 트렁크에 다시 병합하려는 악몽이 될 수 있습니다.  
   
  트렁크 변경 사항을 분기에 정기적으로 병합하면 이러한 상황을 피할 수 있습니다. 정책 구성 : 일주일에 한 번, 지난 주에 해당하는 트렁크 변경 사항을 지점에 병합하십시오.

• http://thedesignspace.net/MT2archives/000680.html
  ... Eclipse CVS 튜토리얼의이 섹션은 Paul Glezen의 Eclipse 웹 사이트 ( Eclipse 및 CVS로 분기) 기사를 기반으로 하며 , EPL 라이센스. 내가 그의 버전을 변경하는 것은 주로 단계별 이미지와 설명으로 확장하고 초보자와 디자이너가 더 쉽게 액세스 할 수 있도록 초보자 자습서와 통합하는 것입니다. 숙련 된 개발자는 아마도 Paul의 버전에서 작업하는 것을 선호 할 것입니다 ...

  • http://www.eclipse.org/articles/article.php?file=Article-BranchingWithEclipseAndCVS/article1.html
  • http://www.eclipse.org/articles/article.php?file=Article-BranchingWithEclipseAndCVS/article2.html

• http://learnsoftwareprocesses.com/2007/12/29/common-branching-strategies/
  ... 일반적인 분기 모델은 다음과 같습니다.  

  1. 분기 별 모델 : 가장 일반적인 분기 전략 중 하나는 분기를 제품 릴리스에 맞추는 것입니다. 지점은 단일 릴리스에 대한 모든 소프트웨어 개발 자산을 보유합니다. 간혹 업데이트를 한 릴리스에서 다른 릴리스로 병합해야하지만 대개는 병합되지 않습니다. 릴리스가 종료되면 지점이 중단됩니다.  
  2. 프로모션 당 지점 : 또 다른 매우 일반적인 접근 방식은 지점을 소프트웨어 자산 프로모션 수준에 맞추는 것입니다. 특정 개발 버전은 모든 통합 및 시스템 테스트가 수행되는 테스트 분기로 분기됩니다. 테스트를 완료하면 소프트웨어 개발 자산이 프로덕션 지점으로 분기되어 궁극적으로 배포됩니다.  
  3. 작업 별 분기 : 중복 된 작업 (또는 활동)과 생산성 손실을 피하기 위해 별도의 분기에서 분리 할 수 ​​있습니다. 이러한 작업은 작업이 완료 되 자마자 병합되어야하는 단기 브랜치입니다. 그렇지 않으면 필요한 병합 작업이 처음에이를 작성하는 데 따른 생산성 이점을 초과 할 수 있습니다.  
  4. 구성 요소 당 분기 : 각 분기를 시스템 아키텍처에 맞출 수 있습니다. 이 전략에서는 개별 구성 요소 (또는 서브 시스템)를 분기합니다. 그런 다음 구성 요소를 개발하는 각 팀은 코드를 통합 지점 역할을하는 개발 라인에 언제 다시 병합할지 결정합니다. 이 전략은 시스템 아키텍처가 있고 개별 구성 요소에 잘 정의 된 인터페이스가있는 경우 효과적입니다. 지점에서 구성 요소를 개발하면 소프트웨어 개발 자산을보다 세밀하게 제어 할 수 있습니다.  
  5. 기술 별 분기 : 시스템 아키텍처와 일치하는 다른 분기 전략. 이 경우 지점은 기술 플랫폼에 맞춰집니다. 공통 코드는 별도의 지점에서 관리됩니다. 지점에서 관리되는 소프트웨어 개발 자산의 고유 한 특성으로 인해 병합되지 않을 것입니다 ...

• http://msdn.microsoft.com/ko-kr/library/bb668955.aspx
  ... 분기 및 병합 지침에 대한 요약은이 가이드의 "소스 제어 지침" 에있는 분기 및 병합 지침을 참조하십시오. ... 분기 할 때 다음을 고려하십시오.

  • 개발 팀이 동일한 파일 세트에서 동시에 작업해야하는 경우가 아니면 분기하지 마십시오. 확실하지 않은 경우 빌드에 레이블을 지정하고 나중에 해당 빌드에서 분기를 작성할 수 있습니다. 분기를 병합하는 것은 특히 시간이 많이 걸리는 경우 시간이 많이 걸리고 복잡 할 수 있습니다.
  • 계층 구조가 아닌 계층 구조를 따라 (분기 트리 위 아래로) 병합하기 만하면 분기 트리를 구성 할 수 있습니다. 계층 구조에서 분기하려면 기본없는 병합을 사용해야하므로 수동 충돌 해결이 더 필요합니다.
  • 분기 계층 구조는 분기 상위 및 분기 하위를 기반으로하며 디스크의 소스 코드의 실제 구조와 다를 수 있습니다. 병합을 계획 할 때는 디스크의 물리적 구조가 아니라 논리적 분기 구조를 염두에 두십시오.
  • 너무 깊게 분기하지 마십시오. 각 병합을 실행하고 충돌을 해결하는 데 시간이 걸리기 때문에 분기 구조가 심하면 하위 분기의 변경 내용이 기본 분기로 전파되는 데 시간이 오래 걸릴 수 있습니다. 이는 프로젝트 일정에 부정적인 영향을 미치고 버그 수정 시간을 늘릴 수 있습니다.
  • 높은 수준으로 분기하고 구성 및 소스 파일을 포함합니다.
  • 시간이 지남에 따라 분기 구조를 발전 시키십시오.
  • 병합하려면 하나 이상의 개발자가 병합을 실행하고 충돌을 해결해야합니다. 병합 된 소스는 빌드를 불안정하게 할 수있는 잘못된 병합 결정을 내리는 경우가 드물지 않으므로 철저히 테스트해야합니다.
  • 지점 계층 구조에서 병합하는 것은 특히 어렵고 자동으로 처리 될 수있는 많은 충돌을 수동으로 처리해야합니다.  
    지점 생성 여부 결정은 실시간으로 병합 병합 비용이 지점 간 충돌 병합 오버 헤드 비용보다 높은지 여부로 줄일 수 있습니다.

• http://kashfarooq.wordpress.com/2009/11/23/bazaar-branching-strategy-with-a-subversion-trunk/

  • http://kashfarooq.wordpress.com/2010/12/16/bazaar-branching-strategy-with-a-subversion-trunk-revised/
  • http://kashfarooq.wordpress.com/2009/11/02/using-bazaar-feature-branches-with-a-subversion-trunk/
  • http://kashfarooq.wordpress.com/2009/09/08/bazaar-or-git-moving-away-from-subversion/
    ...이 Subversion 불만 사항이 익숙한 것 같습니까?
    • "업데이트를 실행해야합니다"라는 메시지가 임의로 표시됩니다. 그런 다음 업데이트를 수행하면 완료하는 데 시간이 걸립니다. 마지막으로 다운로드해야 할 변경 사항이 없음을 알 수 있습니다.
    • "정리를 실행해야합니다"라는 메시지가 임의로 표시됩니다.
    • 큰 병합 문제가 있습니다. 예를 들어, ReSharper를 사용하여 클래스 이름을 바꾸고 다른 일부는 그 클래스를 업데이트했습니다. 그러면 두려운 트리 충돌 오류 (shudder)가 나타납니다. 또는 더 나쁜 것은 전체 네임 스페이스와 폴더의 이름을 바꾸는 것입니다 (더블 셔더). 지금 당신은 정말 고통의 세계에 있습니다.
    • 병합은 점점 더 수동적 인 경향이 있습니다. Subversion에 실마리가 없기 때문에 WinMerge를 자주 사용해야합니다.
    • 당신은 종종 Tortoise가 수정 / 모든 것을 업데이트 / 확인하기를 기다리고 있습니다.  
       
      USB 펜 드라이브에 하위 버전 저장소가 있습니다. 나는 나무 충돌을 일으키고 그 문제를 병합하고, 유일한 사용자입니다!  
       
      주요 문제는 병합하는 것입니다 ...  
       
  • "subversion sucks"는 익숙한 소리입니다. Joel 과 Linus의 이야기를 들어 볼 시간 입니까?

• 
  진화하는 시스템의 경우 릴리스 격리 분기 전략에 대한 모범 사례에 대한 http://social.msdn.microsoft.com/Forums/en/tfsversioncontrol/thread/f127676c-8f05-410c-9a30-0eb43a26a9fa 토론

• http://branchingguidance.codeplex.com/
  "Microsoft Team Foundation Server 분기 지침"-다양한 프로젝트에 맞는 권장 사항이 포함 된 방대한 상세 문서 : HTML 버전 여기 . Microsoft가 단일 규모의 모든 접근 방식으로 브랜치 전략을 믿지 않는다는 것을 증명합니다.

• https://stackoverflow.com/questions/597707/best-branching-strategy-when-doing-continuous-integration
  지속적인 통합을 수행 할 때 사용할 최상의 분기 전략은 무엇입니까? ... 답은 팀의 규모와 소스 제어의 품질 및 복잡한 변경 세트를 올바르게 병합하는 능력에 달려 있습니다 ...

  • http://www.zeroturnaround.com/blog/continuous-integration-and-feature-branches/ Hudson / Jenkins에 대한 구체적인 경험과 몇 가지 유용한 참고 자료를 바탕으로 지속적인 통합을 통한 분기 상호 작용에 대한 자세한 분석
    .. 나의 가장 큰 발견은 CI가 자주 커밋, 푸시 및 피드백을 얻는 것에 관한 것이지만 (즉, CI 클러스터가 워크 스테이션이 같은 시간 내에 제공 할 수없는 피드백을 제공함), 진정한 순수한 CI는 실제로 하나 이상의 요구 사항이 있다는 것입니다. - 팀이 같은 기준에서 작동하는 데 필요한 ...
    재료 사용
    • 여러 지점 모범 사례 – Jenkins 목록에 게시
    • 그것은 복제하지 않고 일부 작업이 각 하나를 실행해야합니다 여러 가지를 처리 할 수 있나요 젠킨스 목록에 포스트 -
    • 지점을 통한 병렬 개발 – Jenkins 목록에 게시
    • Hudson 작업 자동 구성 또는 생성 – stackoverflow.com
    • 여러 지점 개발과의 지속적인 통합 – stackoverflow.com
    • 지속적인 통합에서 여러 지점 처리 – stackoverflow.com
    • 지속적인 통합 – Martin Fowler
    • 지속적인 통합 – Wikipedia

• http://codicesoftware.blogspot.com/2010/03/branching-strategies.html
  ... CVS와 SVN은 완전히 할 수 없었기 때문에 전체 브랜칭 / 병합 전략을 방해했습니다 ... ... 간단한 규칙 : SVN / CVS 사용자에게는 과도하게 들릴 수 있지만 최신 SCM을 사용하면 곧 분기를 만들 수 있으므로 실제 오버 헤드가 없습니다.  
   
  중요 사항 :주의 깊게 살펴보면 작업 분기를 부자 변경 목록으로 사용하는 것에 대해 이야기하고 있음을 알 수 있습니다 ...

• http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_proj.doc/c_bntr_plnbrstrat.htm
  ... 파기 정책은 개발의 영향을받습니다 프로젝트의 목표와 코드베이스의 진화를 제어하는 ​​메커니즘을 제공합니다. Rational ClearCase 버전 제어를 사용하는 조직만큼 다양한 분기 정책이 있습니다. 그러나 모범 사례에 대한 공통 준수를 반영하는 유사성도 있습니다 ...

• http://blogs.open.collab.net/svn/2007/11/branching-strat.html
  ... Subversion 모델 (또는 일반적인 오픈 소스 모델)은 불안정한 트렁크 모델에 표시됩니다. .

• http://en.wikipedia.org/wiki/Trunk_%28software%29
  소프트웨어 개발 분야에서 트렁크 는 개정 관리 중인 파일 트리 의 명명되지 않은 분기 (버전)를 나타냅니다 . 트렁크는 일반적으로 개발이 진행되는 프로젝트의 기반이됩니다. 개발자가 트렁크에서 독점적으로 작업하는 경우 항상 최신 버전의 프로젝트가 포함되어 있지만 가장 불안정한 버전 일 수도 있습니다. 또 다른 방법은 분기를 트렁크에서 분리하고 해당 분기에서 변경 사항을 구현 한 후 분기가 안정적이고 작동하는 것으로 판명되면 변경 사항을 다시 트렁크로 병합하는 것입니다. 개발 모드 및 커밋 에 따라정책은 트렁크에 가장 안정적인 버전 또는 가장 안정적인 버전 또는 중간 버전이 포함될 수 있습니다.  
   
  종종 주요 개발자 작업이 트렁크에서 이루어지고 안정적인 버전이 분기되고 간혹 버그 수정이 분기에서 트렁크로 병합됩니다. 비 트렁크 브랜치에서 향후 버전의 개발을 수행하는 경우 일반적으로 자주 변경되지 않거나 트렁크에 통합 할 준비가 될 때까지 변경이 개발되는 데 오랜 시간이 걸리는 프로젝트에 대해 수행됩니다. .

• http://www.mcqueeney.com/roller/page/tom/20060919
  ...이 문서는 CollabNet이 2006 년 8 월 30 일 실시한 Subversion 모범 사례에 관한 웹 세미나의 메모입니다 . ... 2 개의 조직 전략 : 불안정한 트렁크와 안정된 트렁크 ... ... 가능한 경우 불안정한 트렁크를 준비합니다 ...

• https://stackoverflow.com/questions/153812/subversion-is-trunk-really-the-best-place-for-the-main-development
  SVN에서 트렁크는 주요 개발에 권장되는 장소 이며이 규칙을 사용합니다 모든 프로젝트에 그러나 이것은 간혹 트렁크가 불안정하거나 심지어 부러 졌음을 의미합니다. ... / branch / dev와 같은 일부 브랜치에서 "야생 개발"을 수행하는 것이 좋지 않으며 빌드가 합리적 일 때만 트렁크에 병합하는 것이 좋습니다. 고체?

  • 트렁크는 지속적인 개발이 이루어질 곳입니다. 모든 사람이 변경 사항을 커밋하기 전에 테스트하고 있다면 "깨진"코드에 문제가 없어야합니다. 변경 사항을 코딩 한 후 업데이트 (저장소에서 모든 최신 코드를 가져옴)를 수행하는 것이 좋습니다. 그런 다음 단위 테스트를 빌드하고 수행하십시오. 모든 것이 구축되고 작동하면 체크인해야합니다 ...
  • ... 최고의 트렁크는 최고의 장소가 아닙니다. 우리 조직에서는 항상이 접근 방식을 따릅니다. 트렁크에는 릴리스 코드가 포함되어 있으므로 항상 컴파일됩니다. 새로운 각 릴리스 / 마일스톤으로 새로운 지점을 개설합니다. 개발자가 항목을 소유 할 때마다이 릴리스 브랜치에 새 브랜치를 작성하고 테스트 후에 만 ​​릴리스 브랜치로 병합합니다. 시스템 테스트 후 릴리스 브랜치가 트렁크로 병합됩니다 ...

• http://blog.yclian.com/2009/03/working-on-branches-and-stable-trunk.html
  ... 내가 작업 한 모든 프로젝트에 대해 트렁크에서 일했었습니다. 유일한 개발자 또는 팀은 모든 코드 체크인이 로컬 테스트를 통과했는지 확인했습니다. 그렇지 않으면, 우리가 만든 (우리는 여전히) 등의 버그 수정, 새로운 기능에 대한 큰 코드에 대한 지점은  
   
  약 2 개월 전, 나는 카말 짧은 자식 세션을했고, 그는 나와의 아이디어를 공유 이야기 / 지점을 . 그리고 팀이 더 많은 개발자들과 함께 성장하기 시작하면서 더 많은 분기를 장려해야 할 필요성을 느끼고 이제는 이것이 규칙이되었습니다. CI 설정으로 정의 된 자동 테스트가있는 프로젝트의 경우 안정적인 트렁크가 보장되며이 실습은 매우 적합합니다.  
   
  우리는 git을 사용하지 않고 Subversion을 사용합니다. 왜냐하면 우리가 시작한 방식이므로 지금 (대부분) 여전히 편안합니다 ...

• http://www.ericsink.com/scm/scm_branches.html
  이것은라는 온라인 책의 일부 소스 제어 하우투 소스 제어, 버전 제어 및 구성 관리 ...에, 모범 사례 가이드  
   
  ... 에릭의 선호 분기 연습 ... "기본적으로 불안정한"트렁크를 유지하십시오. 트렁크에서 활발한 개발을 수행하십시오. 릴리스에 접근하면 안정성이 향상됩니다. 배송 후 유지 보수 지점을 만들고 항상 매우 안정적으로 유지하십시오 ...  
   
  ... 다음 장에서는 지점 병합에 대해 설명합니다 ...

• http://marc.info/?l=forrest-dev&m=112504297928196&w=2 Apache Forrest 프로젝트의
  분기 전략을 논의하는 스레드 메일 시작

  • 현재 프로젝트는 릴리스 분기와 함께 불안정한 트렁크 모델을 사용하는 것으로 보입니다.
  • "개발 작업은 SVN 트렁크에서 수행됩니다 ... SVN의"릴리스 지점 "(예 : forrest_07_branch)이 있습니다." ( 프로젝트 가이드 라인 )
  • "릴리스 후보 패키지 빌드 ... 17. SVN에서 유지 보수 브랜치를 작성하십시오 ..."( 릴리스 방법 )

• O'Reilly CVS 분기 문서 :
  http://commons.oreilly.com/wiki/index.php/Essential_CVS/Using_CVS/Tagging_and_Branching#Basically_stable
  

  • ... 기본적으로 안정적인 브랜치 철학은 트렁크에 항상 릴리스 준비가 된 프로젝트 데이터가 포함되어야한다고 명시합니다 ... ...이 철학의 관용적 인 변형으로 개발자 단위 테스트를 통과 한 모든 것을 트렁크, 몸뚱이. 이러한 편안한 접근 방식을 위해서는 릴리스 후보를 분기하여 발행하기 전에 전체 QA 분석을 거쳐야합니다 ...
  • ... 기본적으로 불안정한 철학에 따르면 트렁크에는 안정성에 관계없이 최신 코드가 포함되어야하며 릴리스 후보는 QA를 위해 분기되어야합니다.
     
     
    ... 관용적 인 변형은 실험 코드, 리팩토링 및 기타 특수 코드에 대한 분기를 허용합니다. 지점으로 트렁크를 다시 병합하는 작업은 지점 관리자가 수행합니다. ...
    • 위의 리소스는 내가 수행 한 검색에 나타나지 않았습니다 (CVS 관련 지침은 더 이상 인기가 없습니까?)

• SCM (기사를 억지로)의 모범 사례 에서
  http://www.perforce.com/perforce/papers/bestpractices.html
  ... SCM 구축의 여섯 개 일반 지역과 그 지역의 각 내에서 일부 대단위 모범 사례. 다음 장에서는 각 항목에 대해 설명합니다 ...
  작업 영역, 코드 라인, 분기, 변경 전파, 빌드, 프로세스 ...

여러 팀이 동시에 다른 기능을 수행하는 경우 분기를 생략 할 수있는 방법이 없습니다. 다른 팀이 완료되지 않은 기능을 얻지 못하도록 팀 구성원과 코드를 공유 (일부 구현)해야합니다.

지점은이를 달성하는 가장 쉬운 방법입니다.

지점 수명주기를 단축하고 동시에 두 지점의 동일한 모듈에서 작업하는 것을 피하는 것이 좋지만 충돌 / 병합 문제는 없습니다.

그러나 최근에는 지속적인 통합, 지속적인 전달 등을 수행하기가 더 어려워 지사를 만들지 않는 아이디어를 찾는 사람들이 점점 더 많아지고 있습니다.

그런데 그것은 지속적인 통합, 지속적인 배달, 등을 연습하는 것이 더 어렵게 만들 않는다 당신을 위해 구체적으로?

그렇지 않다면, 나는 당신의 일하는 방식을 바꿀 이유가 없습니다.

물론 현재 진행중인 작업과 현재 모범 사례가 어떻게 발전하고 있는지를 따르는 것이 좋습니다. 그러나 X (및 / 또는 Y 및 / 또는 Z)가 더 이상 퇴색하지 않는다고 말했기 때문에 프로세스 / 도구 / 포기를 포기할 필요는 없다고 생각합니다.

흥미로운 답변이 있습니다. 20 년 이상 나는 지사를 사소하게 사용하는 회사 (일반적으로 지사 릴리스에만 해당)에서 일한 적이 없습니다.

내가 작업 한 대부분의 장소는 상당히 빠른 체크인과 충돌의 빠른 감지 / 해결에 의존합니다. 민첩한 방법론은 양 당사자가 해당 코드에 대해 적극적으로 생각하는 동안 문제를 발견하면 문제를 더 빨리 해결할 수 있다고 가르칩니다.

다른 한편으로, 나는 git을 많이 사용하지 않았으며 아마도이 답변에 영향을 미치는 git 태그를 포함했을 것입니다. 분기 / 병합은 git이 너무 쉽다는 것을 이해합니다.

그렇습니다. 분기를 사용하여 (적어도 중간 정도의) 개발 노력을 분리해야합니다. " 언제 분기해야합니까? " 를 참조하십시오 .

먼저 "중간 체크 포인트 커밋"(롤백 또는 git bisect. 개인 분기 (푸시되지 않음)와 공개 분기를 구별하려면 " 깃트 워크 플로우 이해
"를 참조하십시오. 병합하려는 분기 내에서 필요한 정리를 수행하는 경우 ff 병합 (앞으로 병합)으로 완료됩니다. . " git이 기본적으로 빨리 병합을 사용하는 이유는 무엇입니까? " 도 참조하십시오 .

반드시 지점을 사용해야합니다. 거기에는 여러 가지 장점이 있습니다.

• HD 실패, 랩톱 분실 등으로 인해 작업을 잃어 버릴 염려가 있다면 주 작업 CI를 손상시키지 않을 것입니다.
• 당신은 여전히 ​​CI를 할 수 있습니다. 당신의 브랜치를보기 위해 자신의 로컬 CI를 설정하기 만하면됩니다.
• 피처가 갑자기 보류 된 경우 (절대로 발생하지 않음) 파킹 할 수 있습니다.

너무 어려운 것은 결코 변명의 여지가 없습니다. 항상 제대로하려면 더 많은 노력이 필요합니다.

두 팀이 자체 지사에서 작업하는 경우 두 팀이 master지사를 통합하더라도 다른 팀의 변경 사항을 볼 수 없습니다 . 그것은 그들의 개발 지사가 떨어져 나갈 것이며, 한 팀이 합병 master한다면 다른 팀은 많은 변화를 리베이스해야합니다.

따라서 기능에 대한 분기가있는 경우에도 모든 리팩토링의 '백 포트'를 마스터 분기로 '백 포트'하고 새 기능에 대해서만 분기를 유지하는 것이 좋습니다.

• 백 포트 리팩토링

때로는 프로덕션에 들어 가지 않아야 할 테스트되지 않은 새로운 기능을 비활성화하기 위해 기능 스위치를 사용하는 것이 더 쉽다고 생각합니다. 이렇게하면 다른 모든 팀이 변경 사항을 볼 수 있으며 빅뱅 합병이 발생하지 않습니다.

• 기능 스위치 사용

우리는 방금이 과정을 거쳤습니다. 먼저 우리는 GIT / SVN 토론 전체를 가졌습니다.

대기업은 모두 트렁크 기반 전략을 사용합니다.이 전략은 모든 사람이 같은 지점에서 일하고 구축 및 지속적인 통합이 해당 지점에서 이루어집니다. 코드 모듈화, 기능 전환 및 영리한 툴링을 사용하여 충돌을 피할 수 있습니다. 어려워요. 왜냐하면. 그러나이 토론을한다면 브랜칭에 대한 사람들의 환상에 희생 되었기 때문입니다. 일부는 그들이 완전 sarbanes-oxley 호환 프로모션 분기 메커니즘과 함께 여기에 Insert SCM 도구 를 사용한다고 주장하며 , 모두 훌륭합니다. 그들은 거짓말을하거나 자신을 속이거나 또는 당신과 같은 규모의 시스템에서 일하지 않습니다.

분기 및 병합이 어렵습니다. 특히 정기적으로 마음을 바꾸고 롤백 등을 요구하는 비즈니스가있는 경우.

이 문장은 당신의 생명을 구할 수 있습니다 : SCM의 내용은 내장 된 인공물의 내용과 동일하지 않습니다!

분기에 문제가있는 경우 SCM을 잘못 사용하고 있기 때문입니다. 우리는 모두 몇 년 동안 해왔습니다. SCM을 사용하여 최종 빌드에 들어갈 시스템을 결정했습니다.

그것은 SCM의 일이 아닙니다. SCM은 영화화 된 파일 서버입니다. SCM에서 어떤 파일이 사용자의 빌드로 들어가는 지 결정하는 작업은 빌드 툴링에 속합니다.

모듈 A가 작업 중이며 주간 릴리스에 들어갑니다. 모듈 B는 모듈 A이지만 프로젝트 X가 포함되어 있으며 동일한 브랜치에서 작업 중이지만 릴리스에 내장되어 있지 않습니다. 나중에 어느 시점에서 프로젝트 X를 릴리스하려고합니다. 따라서 빌드 도구에 모듈 A의 삽입을 중지하고 모듈 B의 삽입을 시작하도록 지시하십시오.

이것에 대해 많은 외침과 울부 짖음이있을 것입니다. 끔찍하고 일반적인 하울링. 아무리 영리하더라도 파일 저장소처럼 단순한 것을 둘러싼 감정의 수준입니다.

그러나 당신의 대답이 있습니다.

분기의 주요 문제점은 개발이 완료 될 때 기본 분기로 다시 병합하기가 어렵다는 것입니다. 병합은 수동이고 오류가 발생하기 쉬운 프로세스 일 수 있으므로 대부분 피해야합니다.

분기를 선호하는 주목할만한 예외는 대규모 리팩토링, 스프린트보다 시간이 오래 걸리는 거대한 기능 또는 대부분의 스프린트 동안 다른 기능의 개발을 방해하는 파괴적인 기능입니다.

이런 종류의 브랜치 구성을 권장합니다.

출시-테스트-개발

그런 다음 개발에서 개발자 및 / 또는 기능별로 분기합니다.

개발자들은 각각 매일 이상적으로 (컴파일을 제공하는) 개발 브랜치와 함께 플레이하고 개발 브랜치에 합류 할 브랜치를 가지고 있습니다.

이러한 종류의 체계는 동일한 코드베이스의 많은 개발자 및 여러 프로젝트에서 실제로 잘 작동합니다.

우리 는 분기를 사용하지만 세분화 된 기능 수준에서는 사용하지 않습니다. 각 스프린트마다 브랜치를 사용합니다. 본질적으로 분기 는 기능 또는 스프린트 레이어에서 SOC 의 개념을 시뮬레이션하기 때문에 나쁜 IMO가 아닙니다 . 어떤 지점이 어떤 기능이나 스프린트에 속하는지 쉽게 인식하고 관리 할 수 ​​있습니다.

IMHO, 대답은 YES 입니다. 우리는 여전히 분기를 사용해야합니다.

우리 조직의 프로세스는 지점 과 광범위한 통합 프로세스를 사용합니다.

높은 수준의 관점에서, 개발자들은 메인 라인과의 병합에 대해 너무 걱정하지 않고 단지 브랜치에 전념합니다. (반) 자동 프로세스는 메인 라인으로 예정된 기능을 확인하고 해당 지점을 병합하고 제품을 빌드합니다. 프로세스 추적 도구에서 병합하는이 프로세스를 실제로 통합하여 빌드 도구가 병합 할 분기를 알기 때문에 프로세스가 작동합니다.