Subversion 저장소에서 "branch", "tag"및 "trunk"는 무엇을 의미합니까?
답변:
흠, Nick re tag가 지점과 비슷하다는 것에 동의하지 않습니다. 태그는 단지 마커입니다
트렁크 는 프로젝트의 시작부터 현재까지의 발전의 주체가 될 것입니다.
분기 는 트렁크의 코드 무결성을 유지하면서 코드의 주요 변경 사항을 적용하는 데 사용되는 트렁크의 특정 지점에서 파생 된 코드의 사본입니다. 주요 변경 사항이 계획에 따라 작동하면 일반적으로 트렁크로 다시 병합됩니다.
태그 는 보존하려는 트렁크 또는 지점의 특정 시점입니다. 보존의 두 가지 주요 이유는 알파, 베타, RC 또는 RTM인지 여부에 관계없이 소프트웨어의 주요 릴리스이거나 트렁크의 주요 개정이 적용되기 전에 소프트웨어의 가장 안정적인 지점이기 때문입니다.
오픈 소스 프로젝트에서 프로젝트 이해 관계자가 트렁크로 받아들이지 않는 주요 지점은 포크 의 기반이 될 수 있습니다 ( 예 : 다른 소스 코드와 공통 원점을 공유하는 완전히 분리 된 프로젝트).
분기 및 태그 하위 트리는 다음과 같은 방식으로 트렁크와 구별됩니다.
Subversion을 사용하면 sysadmins 는 특정 이벤트가 발생할 때 실행되도록 트리거되는 후크 스크립트 를 작성할 수 있습니다. 예를 들어 리포지토리에 변경 내용 커밋 일반적인 Subversion 저장소 구현에서는 "/ tag /"가 포함 된 경로를 작성 후 쓰기 금지 된 것으로 취급하는 것이 매우 일반적입니다. 결과적으로 일단 생성 된 태그는 변경할 수 없습니다 (적어도 "일반적인"사용자에게는). 이는 태그 가 변경된 객체의 부모 노드 인 경우 추가 변경을 방지하여 불변성을 강제하는 후크 스크립트를 통해 수행됩니다 .
또한 Subversion은 버전 1.5 이후 "분기 병합 추적"과 관련된 기능을 추가하여 분기에 커밋 된 변경 사항 을 증분 "스마트"병합을 지원하여 트렁크로 다시 병합 할 수 있습니다.
Tags디렉토리는 종종 일반 사용자의 마일스톤 테스트 및 확인에도 사용됩니다. 이것은 프로토 타입도 넣을 수있는 좋은 장소입니다 (제 머리 위에 몇 가지 아이디어 만 있습니다).
먼저 @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에 대한 폴더입니다. 프로젝트를 구성하는 데 일반적으로 허용되는 방법입니다.
트렁크는 당신이 개발중인 메인 라인을 유지하는 곳입니다. 브랜치 폴더는 브랜치를 생성 할 수있는 곳으로 짧은 포스트에서는 설명하기 어렵습니다.
브랜치는 트렁크와 별도로 작업하는 프로젝트의 서브 세트 사본입니다. 어딘가에 가지 않을 수도있는 실험이나 다음 릴리스를위한 것일 수도 있으며, 나중에 안정 될 때 트렁크로 다시 병합 될 수도 있습니다.
그리고 tags 폴더는 일반적으로 릴리스 체크 포인트에서 태그가 지정된 저장소 사본을 작성하기위한 것입니다.
그러나 내가 말했듯이 SVN에게 폴더는 폴더입니다. branch,trunk 및 태그 단지 컨벤션 있습니다.
나는 '복사'라는 단어를 자유롭게 사용하고 있습니다. SVN은 실제로 저장소에서 사물의 전체 사본을 만들지 않습니다.
트렁크는 최신의 소스 코드와 기능을 보유하고있는 개발 라인입니다. 최신 버그 수정과 함께 프로젝트에 추가 된 최신 기능이 있어야합니다.
그만큼 지점은 일반적으로 다른 것이다 트렁크 (또는 다른 개발 라인)에서 일을 멀리 할하는 데 사용되는 휴식 빌드를. 새로운 기능은 종종 지점에 구축 된 다음 트렁크로 다시 병합됩니다. 분기에는 종종 분기 된 개발 라인에 대해 승인되지 않은 코드가 포함됩니다. 예를 들어, 프로그래머는 브랜치에서 무언가에 대한 최적화를 시도하고 최적화가 만족 스러우면 개발 라인으로 다시 병합 할 수 있습니다.
태그는 특정 시간에 저장소의 스냅 샷입니다. 이것들에 대한 개발은 일어나지 않아야합니다. 가장 자주 클라이언트에 공개 된 내용의 사본을 가져 와서 클라이언트가 사용중인 내용에 쉽게 액세스 할 수 있습니다.
다음은 리포지토리에 대한 훌륭한 가이드로 연결되는 링크입니다.
Wikipedia의 기사도 읽을 가치가 있습니다.
이제는 소프트웨어 개발에 관한 것입니다. 어떤 것에 대해서도 일관된 지식이 없으며, 모든 사람들이 자신의 방식을 가지고있는 것처럼 보이지만, 어쨌든 비교적 젊은 훈련이기 때문입니다.
여기 내 단순하고 간단한 방법이 있습니다.
트렁크 -트렁크 디렉토리에는 가장 최신의 승인 된 병합 작업 본문이 포함됩니다. 많은 사람들이 고백 한 내용과 달리 내 트렁크는 깨끗하고 깔끔하며 승인 된 작업만을위한 것이며 개발 영역이 아니라 릴리스 영역입니다.
트렁크가 모두 릴리스 준비가 된 것으로 보이는 특정 시점에 태그가 지정되고 해제됩니다.
가지 -branches 디렉토리에는 실험 및 진행중인 작업이 포함되어 있습니다. 지사 아래의 작업은 트렁크에 병합되도록 승인 될 때까지 유지됩니다. 나를 위해, 이것은 모든 작업이 수행되는 영역입니다.
예를 들어, 나는 제품에 5 번째 개발 라운드를위한 반복 -5 브랜치 , 9 번째 실험을위한 프로토 타입 -9 브랜치 등을 가질 수 있습니다 .
tags -tags 디렉토리에는 승인 된 분기 및 트렁크 릴리스의 스냅 샷이 있습니다. 분기가 트렁크에 병합되도록 승인되거나 트렁크로 릴리스 될 때마다 승인 된 분기 또는 트렁크 릴리스의 스냅 샷이 태그 아래에 생성됩니다.
나는 태그를 사용하여 관심을 끌기 위해 시간을 거슬러 앞뒤로 이동할 수 있다고 가정합니다.
OpenCV 2 Computer Vision Application Programming Cookbook 작성자 의 웹 사이트를 검색 할 때 SVN에 관한이 훌륭한 자습서를 찾았으며 공유해야한다고 생각했습니다.
그는 SVN 사용법과 'trunk', 'tag'및 'branch'라는 문구에 대한 자습서를 제공합니다.
그의 튜토리얼에서 직접 인용 :
팀이 현재 작업중인 소프트웨어 프로젝트의 현재 버전은 일반적으로 trunk 라는 디렉토리 아래에 있습니다 . 프로젝트가 진행됨에 따라 개발자는 해당 버전 수정 버그를 업데이트하고 새 기능을 추가)하고 해당 디렉토리에 변경 사항을 제출합니다.
특정 시점에서, 개발의이 단계에서와 같이 버전을 고정하고 소프트웨어의 스냅 샷을 캡처 할 수 있습니다. 이는 일반적으로 소프트웨어의 공식 버전 (예 : 고객에게 제공 할 소프트웨어)에 해당합니다. 이 스냅 샷은 프로젝트 의 tags 디렉토리에 있습니다.
마지막으로, 어떤 시점에서 소프트웨어의 새로운 개발 라인을 작성하는 것이 종종 유용합니다. 예를 들어, 소프트웨어를 수정해야하는 대체 구현을 테스트하려고하지만 새로운 솔루션을 채택할지 여부를 결정할 때까지 이러한 변경 사항을 기본 프로젝트에 제출하지 않으려는 경우에 발생합니다. 그러면 주요 팀은 프로젝트를 계속 진행하면서 다른 개발자는 프로토 타입을 작업 할 수 있습니다. 이 새로운 프로젝트 개발 라인을 branch 라는 디렉토리에 두어야합니다 .
트렁크 디렉토리는 가장 최근의 변경 사항을 유지하는 데 사용되므로 가장 익숙한 디렉토리입니다. 기본 코드베이스는 트렁크에 있어야합니다.
가지 디렉토리는 가지에 관계없이 가지를 보유하기위한 것입니다.
tags 디렉토리는 기본적으로 특정 파일 세트에 태그를 지정하기위한 것입니다. 이 버전에서는 "1.0"을 이러한 파일로, "1.1"을 이러한 파일에서이 파일로 사용하려는 릴리스와 같은 작업에 대해이 작업을 수행합니다. 일반적으로 태그를 만든 후에는 수정하지 않습니다. 태그에 대한 자세한 내용은 4 장. 분기 및 병합 ( Subversion을 사용한 버전 제어에서 )을 참조하십시오.
모두가 약간 다른 정의를 갖는 이유 중 하나는 Subversion 이 브랜치 및 태그를 전혀 지원 하지 않기 때문 입니다. Subversion은 기본적으로 말합니다 : 우리는 다른 시스템 에서 모든 기능을 갖춘 브랜치 및 태그를 살펴 보았지만 유용하지 않아 아무것도 구현하지 않았습니다. 대신 이름 규칙을 사용 하여 새 디렉토리로 복사하십시오 . 물론 모든 사람은 약간 다른 규칙을 가질 수 있습니다. 실제 태그와 단순한 복사 + 명명 규칙 의 차이점을 이해하려면 Wikipedia 항목 Subversion 태그 및 분기를 참조하십시오 .
태그 = 정의 된 시간 조각으로 일반적으로 릴리스에 사용됩니다.
나는 이것이 일반적으로 "태그"의 의미라고 생각합니다. 그러나 Subversion에서 :
그들은 실제로 공식적인 의미가 없습니다. 폴더는 SVN에 대한 폴더입니다.
분기 또는 태그에 대해 전혀 모르는 개정 제어 시스템이 다소 혼란 스럽습니다. 구현 관점에서 볼 때 "복사본"을 만드는 Subversion 방식은 매우 영리하다고 생각하지만,이를 누수 추상화 라고 부릅니다 .
아니면 CVS를 너무 오래 사용했을 수도 있습니다.
'태그'가 무엇인지 잘 모르겠지만 분기는 매우 일반적인 소스 제어 개념입니다.
기본적으로 분기는 트렁크에 영향을주지 않고 코드 변경 작업을 수행하는 방법입니다. 상당히 복잡한 새로운 기능을 추가하고 싶다고 가정 해보십시오. 변경 사항을 확인하면서 기능을 체크인 할 수 있지만 기능이 완료 될 때까지 트렁크에 영향을 미치지 않기를 원합니다.
먼저 지점을 만듭니다. 이것은 기본적으로 지점을 만든 시점의 트렁크 사본입니다. 그런 다음 지점에서 모든 작업을 수행합니다. 지점에서 변경 한 내용은 트렁크에 영향을 미치지 않으므로 트렁크를 계속 사용할 수 있으므로 다른 사람이 계속 작업 할 수 있습니다 (버그 수정 또는 작은 향상). 기능이 완료되면 지점을 트렁크에 다시 통합합니다. 이렇게하면 모든 변경 사항이 지점에서 트렁크로 이동합니다.
사람들이 가지에 사용하는 많은 패턴이 있습니다. 여러 주요 버전이 동시에 지원되는 제품이있는 경우 일반적으로 각 버전은 지점이됩니다. 내가 일하는 곳에 QA 지점과 생산 지점이 있습니다. 코드를 QA로 릴리스하기 전에 변경 사항을 QA 브랜치에 통합 한 다음 여기에서 배치합니다. 프로덕션으로 출시 할 때 QA 지점에서 프로덕션 지점으로 통합되므로 프로덕션에서 실행중인 코드가 QA 테스트와 동일하다는 것을 알 수 있습니다.
여기에 Wikipedia 항목이 있습니다. 아마도 내가 할 수있는 것보다 더 잘 설명 할 수 있기 때문입니다. :)