[svn] Subversion 저장소에서 “branch”, “tag”및 “trunk”는 무엇을 의미합니까?

Program / 글쓴이

Subversion (및 일반적인 저장소) 토론 에서이 단어를 많이 보았습니다. 지난 몇 년 동안 프로젝트에 SVN 을
사용해 왔지만 이러한 디렉토리의 전체 개념을 파악한 적이 없습니다.

그들은 무엇을 의미합니까?

답변

흠, Nick re tag가 지점과 비슷하다는 것에 동의하지 않습니다. 태그는 단지 마커입니다

  • 트렁크 는 프로젝트의 시작부터 현재까지의 발전의 주체가 될 것입니다.

  • 분기 는 트렁크의 코드 무결성을 유지하면서 코드의 주요 변경 사항을 적용하는 데 사용되는 트렁크의 특정 지점에서 파생 된 코드의 사본입니다. 주요 변경 사항이 계획에 따라 작동하면 일반적으로 트렁크로 다시 병합됩니다.

  • 태그 는 보존하려는 트렁크 또는 지점의 특정 시점입니다. 보존의 두 가지 주요 이유는 알파, 베타, RC 또는 RTM인지 여부에 관계없이 소프트웨어의 주요 릴리스이거나 트렁크의 주요 개정이 적용되기 전에 소프트웨어의 가장 안정적인 지점이기 때문입니다.

오픈 소스 프로젝트에서 프로젝트 이해 관계자가 트렁크로 받아들이지 않는 주요 지점은 포크 의 기반이 될 수 있습니다 ( 예 : 다른 소스 코드와 공통 원점을 공유하는 완전히 분리 된 프로젝트).

분기 및 태그 하위 트리는 다음과 같은 방식으로 트렁크와 구별됩니다.

Subversion을 사용하면 sysadmins 는 특정 이벤트가 발생할 때 실행되도록 트리거되는 후크 스크립트 를 작성할 수 있습니다. 예를 들어 리포지토리에 변경 내용 커밋 일반적인 Subversion 저장소 구현에서는 “/ tag /”가 포함 된 경로를 작성 후 쓰기 금지 된 것으로 취급하는 것이 매우 일반적입니다. 결과적으로 일단 생성 된 태그는 변경할 수 없습니다 (적어도 “일반적인”사용자에게는). 이는 태그 가 변경된 객체의 부모 노드 인 경우 추가 변경을 방지하여 불변성을 강제하는 후크 스크립트를 통해 수행됩니다 .

또한 Subversion은 버전 1.5 이후 “분기 병합 추적”과 관련된 기능을 추가하여 분기에 커밋 된 변경 사항 을 증분 “스마트”병합을 지원하여 트렁크로 다시 병합 할 수 있습니다.

답변

먼저 @AndrewFinnell과 @KenLiu가 지적했듯이 SVN에서 디렉토리 이름 자체는 아무 의미도 없습니다. “트렁크, 분기 및 태그”는 대부분의 리포지토리에서 사용되는 일반적인 규칙입니다. 모든 프로젝트가 모든 디렉토리를 사용하는 것은 아니며 ( “태그”를 전혀 사용하지 않는 것이 일반적으로 일반적 임), 관례를 어기는 것이 종종 혼란 스럽지만 실제로 원하는 것을 호출하지 못하게하는 것은 없습니다.

분기 및 태그의 가장 일반적인 사용 시나리오를 설명하고 사용 방법에 대한 예제 시나리오를 제공합니다.

  • 간선 : 주요 개발 지역. 여기에 코드의 다음 주요 릴리스가 있으며 일반적으로 모든 최신 기능이 있습니다.

  • 지점 : 메이저 버전을 릴리스 할 때마다 지점이 생성됩니다. 이를 통해 최신 (아마도 미완성 또는 테스트되지 않은) 기능을 릴리스하지 않고도 버그 수정을 수행하고 새 릴리스를 만들 수 있습니다.

  • 태그 : 버전 (최종 릴리스, RC (릴리스 후보) 및 베타)을 릴리스 할 때마다 해당 태그를 만듭니다. 이를 통해 해당 상태의 코드를 특정 시점으로 복사하여 이전 버전에서 필요한 경우 버그를 재현하고 이전 버전을 그대로 다시 릴리스 할 수 있습니다. SVN의 브랜치와 태그는 가볍습니다. 서버에서는 파일의 전체 사본을 만들지 않고 단지 몇 바이트 만 차지하는 “이 파일들은이 개정판에서 복사되었습니다”라는 표시를합니다. 이를 염두에두고 릴리스 된 코드에 대한 태그 작성에 대해 걱정하지 않아도됩니다. 앞서 언급했듯이 태그는 종종 생략되고 대신 변경 로그 또는 기타 문서가 릴리스 될 때 개정 번호를 명시합니다.

예를 들어, 새로운 프로젝트를 시작한다고 가정 해 봅시다. “트렁크”에서 작업을 시작하여 결국 버전 1.0으로 릴리스됩니다.

  • 트렁크 /-개발 버전, 곧 1.0
  • 가지 /-비어 있음

1.0.0이 완료되면 트렁크를 새로운 “1.0”분기로 분기하고 “1.0.0”태그를 만듭니다. 이제 트렁크에서 1.1이 계속되는 작업을 수행하십시오.

  • 트렁크 /-개발 버전, 곧 1.1
  • branches / 1.0-1.0.0 릴리스 버전
  • tags / 1.0.0-1.0.0 출시 버전

코드에서 몇 가지 버그가 발생하여 트렁크에서 수정 한 다음 수정 사항을 1.0 분기로 병합합니다. 반대의 작업을 수행하고 1.0 분기의 버그를 수정 한 다음 다시 트렁크로 병합 할 수 있지만 일반적으로 프로젝트는 단방향으로 만 병합하여 무언가 누락 될 가능성을 줄입니다. 버그는 1.1에서 더 이상 사용되지 않으므로 1.0에서만 수정 될 수 있습니다. 중요하지 않습니다. 1.0에서 수정 된 것과 동일한 버그로 1.1을 릴리스하지 않기를 원합니다.

  • 트렁크 /-개발 버전, 곧 1.1
  • 분기 /1.0-곧 1.0.1 릴리스
  • tags / 1.0.0-1.0.0 출시 버전

충분한 버그 (또는 하나의 중요한 버그)를 찾으면 1.0.1 릴리스를 수행하기로 결정합니다. 따라서 1.0 분기에서 “1.0.1”태그를 만들고 코드를 해제하십시오. 이 시점에서 트렁크는 1.1이 될 것을 포함하고 “1.0”브랜치는 1.0.1 코드를 포함합니다. 다음에 1.0으로 업데이트를 릴리스하면 1.0.2가됩니다.

  • 트렁크 /-개발 버전, 곧 1.1
  • 분기 /1.0-곧 1.0.2 릴리스
  • tags / 1.0.0-1.0.0 출시 버전
  • tags / 1.0.1-1.0.1 출시 버전

결국 1.1을 출시 할 준비가 거의되었지만 베타를 먼저하고 싶습니다. 이 경우 “1.1”분기와 “1.1beta1″태그를 사용할 수 있습니다. 이제 1.2 (또는 2.0)가 될 것에 대한 작업은 트렁크에서 계속되지만 1.1에 대한 작업은 “1.1”분기에서 계속됩니다.

  • 트렁크 /-개발 버전, 곧 1.2
  • 분기 /1.0-곧 1.0.2 릴리스
  • 분기 /1.1-향후 1.1.0 릴리스
  • tags / 1.0.0-1.0.0 출시 버전
  • tags / 1.0.1-1.0.1 출시 버전
  • tags / 1.1beta1-1.1 베타 1 릴리스 버전

1.1 final을 릴리스하면 “1.1”분기에서 “1.1”태그를 수행합니다.

원하는 경우 세 가지 분기 (1.0, 1.1 및 트렁크)간에 버그 수정을 이식하여 1.0을 계속 유지할 수도 있습니다. 중요한 점은 유지 관리하는 소프트웨어의 모든 주요 버전마다 해당 버전의 최신 코드 버전이 포함 된 분기가 있다는 것입니다.

분기의 또 다른 용도는 기능입니다. 여기에서 트렁크 (또는 릴리스 분기 중 하나)를 분기하고 새로운 기능을 별도로 작업합니다. 기능이 완료되면 기능을 다시 병합하고 분기를 제거합니다.

  • 트렁크 /-개발 버전, 곧 1.2
  • 분기 /1.1-향후 1.1.0 릴리스
  • 지점 / ui-rewrite-실험 기능 지점

이것의 아이디어는 당신이 파괴적인 것 (다른 사람들이 그들의 일을하는 것을 방해하거나 방해 할 것), 실험적인 것, 심지어는 시간이 걸리는 것 같은 일을 할 때입니다 (트렁크에서 1.2 분기 할 준비가되었을 때 1.2 릴리스를 유지하는 것이 두려운 경우) 분기에서 분리하여 수행 할 수 있습니다. 일반적으로 변경 사항을 항상 병합하여 트렁크와 함께 최신 상태로 유지하므로 완료되면 다시 통합하기가 쉬워집니다 (트렁크로 다시 병합).

또한 여기서 사용한 버전 관리 체계는 여러 가지 중 하나 일뿐입니다. 일부 팀은 버그 수정 / 유지 보수 릴리스를 1.1, 1.2 등으로, 주요 변경 사항을 1.x, 2.x 등으로 수행합니다. 여기서 사용법은 동일하지만 지점 이름을 “1”또는 “1로 지정할 수 있습니다. “1.0”또는 “1.0.x”대신 .x “. ( 시맨틱 버전 관리 는 버전 번호를 사용하는 방법에 대한 좋은 가이드입니다).

답변

Nick이 말한 것 외에도 Streamed Lines : 병렬 소프트웨어 개발을위한 분기 패턴 에서 자세한 내용을 확인할 수 있습니다 .

여기에 이미지 설명을 입력하십시오

이 그림 main에서 트렁크 rel1-maint는 브랜치이며 1.0태그입니다.

답변

일반적으로 (툴 불가지론 적 관점에서) 브랜치는 병렬 개발에 사용되는 메커니즘입니다. SCM은 0에서 n 개의 분기를 가질 수 있습니다. Subversion은 0입니다.

  • 트렁크 는 Subversion 에서 권장 하는 기본 브랜치 이지만 직접 만들지는 않습니다. ‘메인’또는 ‘릴리스’라고 부르거나 전혀 없을 수도 있습니다!

  • 지점 은 개발 노력을 나타냅니다. 자원의 이름을 ‘vonc_branch’와 같이 지정하지 말고 다음과 같이 지정하면 안됩니다.

    • ‘myProject_dev’또는 ‘myProject_Merge’의 목적
    • 릴리스 경계 ‘myProjetc1.0_dev’또는 myProject2.3_Merge ‘또는’myProject6..2_Patch1 ‘…

  • 태그 는 해당 상태로 쉽게 돌아갈 수 있도록 파일의 스냅 샷입니다.
    문제는 Subversion에서 태그와 분기가 동일하다는 것 입니다. 그리고 나는 편집증 접근법을 확실히 추천 할 것입니다 :

    Subversion과 함께 제공된 액세스 제어 스크립트 중 하나를 사용하여 다른 사람이 태그 영역에서 새 사본을 작성하는 것 외에는 아무것도하지 못하게 할 수 있습니다.

태그가 최종입니다. 내용은 절대 바뀌지 않아야합니다. 못. 이제까지. 릴리스 노트에서 줄을 잊었습니까? 새 태그를 작성하십시오. 오래된 것을 제거하거나 제거하십시오.

이제 저는 “그러한 것들과 같은 가지들을 다시 합쳐서 마지막으로 트렁크 가지에 합치는 것에 대해”많이 읽었습니다. 이를 병합 워크 플로 라고하며 여기 에는 필수 항목 이 없습니다 . 트렁크 브랜치를 가지고 있기 때문에 아무것도 병합 하지 않아도됩니다 .

일반적으로 트렁크 브랜치는 개발의 현재 상태를 나타낼 수 있지만 간단한 순차 프로젝트, 즉 다음과 같은 프로젝트를위한 것입니다.

  • ‘사전’개발 없음 (다음 차세대 버전 준비를 위해 현재 ‘트렁크’개발과 호환되지 않는 변경 사항을 암시)
  • 대규모 리팩토링 없음 (새로운 기술 선택 테스트 용)
  • 이전 릴리스를 장기간 유지 보수하지 않음

이러한 시나리오 중 하나 (또는 ​​모두)를 사용하면 네 개의 ‘트렁크’, 네 개의 ‘현재 개발’을 얻게되며 병렬 개발에서 수행하는 모든 작업이 반드시 ‘트렁크’로 다시 병합되어야하는 것은 아닙니다.

답변

SVN에서 태그와 분기는 실제로 비슷합니다.

꼬리표 = 정의 된 시간 조각으로 일반적으로 릴리스에 사용

Branch = 또한 개발을 계속할 수있는 정의 된 슬라이스이며 일반적으로 1.0, 1.5, 2.0 등과 같은 메이저 버전에 사용되며 분기를 해제 할 때 분기를 태그합니다. 이를 통해 트렁크의 주요 변경 사항을 진행하면서 프로덕션 릴리스를 계속 지원할 수 있습니다.

트렁크 = 개발 작업 공간, 여기에서 모든 개발이 수행되고 지점 릴리스에서 변경 사항이 다시 병합됩니다.

답변

그들은 실제로 공식적인 의미가 없습니다. 폴더는 SVN에 대한 폴더입니다. 프로젝트를 구성하는 데 일반적으로 허용되는 방법입니다.

  • 트렁크는 당신이 개발중인 메인 라인을 유지하는 곳입니다. 브랜치 폴더는 브랜치를 생성 할 수있는 곳으로 짧은 포스트에서는 설명하기 어렵습니다.

  • 브랜치는 트렁크와 별도로 작업하는 프로젝트의 서브 세트 사본입니다. 어딘가에 가지 않을 수도있는 실험이나 다음 릴리스를위한 것일 수도 있으며, 나중에 안정 될 때 트렁크로 다시 병합 될 수도 있습니다.

  • 그리고 tags 폴더는 일반적으로 릴리스 체크 포인트에서 태그가 지정된 저장소 사본을 작성하기위한 것입니다.

그러나 내가 말했듯이 SVN에게 폴더는 폴더입니다. branch,trunk 및 태그 단지 컨벤션 있습니다.

나는 ‘복사’라는 단어를 자유롭게 사용하고 있습니다. SVN은 실제로 저장소에서 사물의 전체 사본을 만들지 않습니다.

답변

트렁크는 최신의 소스 코드와 기능을 보유하고있는 개발 라인입니다. 최신 버그 수정과 함께 프로젝트에 추가 된 최신 기능이 있어야합니다.

그만큼 지점은 일반적으로 다른 것이다 트렁크 (또는 다른 개발 라인)에서 일을 멀리 할하는 데 사용되는 휴식 빌드를. 새로운 기능은 종종 지점에 구축 된 다음 트렁크로 다시 병합됩니다. 분기에는 종종 분기 된 개발 라인에 대해 승인되지 않은 코드가 포함됩니다. 예를 들어, 프로그래머는 브랜치에서 무언가에 대한 최적화를 시도하고 최적화가 만족 스러우면 개발 라인으로 다시 병합 할 수 있습니다.

태그는 특정 시간에 저장소의 스냅 샷입니다. 이것들에 대한 개발은 일어나지 않아야합니다. 가장 자주 클라이언트에 공개 된 내용의 사본을 가져 와서 클라이언트가 사용중인 내용에 쉽게 액세스 할 수 있습니다.

다음은 리포지토리에 대한 훌륭한 가이드로 연결되는 링크입니다.

Wikipedia의 기사도 읽을 가치가 있습니다.