버전 관리

이 글은 검증을 위해 추가 인용문이 필요합니다. 신뢰할 수 있는 출처에 인용문을 추가하여 이 기사를 개선하는 데 도움을 주십시오. 조달되지 않은 자재는 제거될 수 있습니다.출처 : '버전 관리'– 뉴스 · 신문 · 서적 · 학자 · JSTOR (2011년 4월) (이 템플릿 메시지 삭제 방법 및 삭제 시기 확인)

소프트웨어 엔지니어링에서 버전 제어(리비전 제어, 소스 제어 또는 소스 코드 관리라고도 함)는 컴퓨터 프로그램, 문서, 대규모 웹 사이트 또는 기타 정보 모음에 대한 변경을 관리하는 시스템 클래스입니다.버전 제어는 소프트웨어 구성 ^[1]관리의 구성 요소입니다.

변경은 보통 "리비전 번호", "리비전 수준" 또는 단순히 "리비전"이라고 하는 숫자 또는 문자 코드로 식별됩니다.예를 들어, 파일의 초기 세트는 "revision 1"입니다.첫 번째 변경이 이루어지면 결과 세트는 "revision 2"가 됩니다.각 리비전은 타임스탬프 및 변경 담당자와 관련지어집니다.리비전은 비교, 복원 및 일부 파일 형식과 ^[2]병합할 수 있습니다.

리비전을 정리하고 제어하는 논리적인 방법은 쓰기가 존재하는 한 거의 오랫동안 존재해 왔지만 컴퓨팅 시대가 열리면서 리비전 관리는 훨씬 더 중요해지고 복잡해졌습니다.서적판 및 사양 개정판의 번호 부여는 인쇄 전용 시대로 거슬러 올라가는 예입니다.현재 가장 성능이 뛰어나고 복잡한 리비전 제어 시스템은 소프트웨어 개발에서 사용되는 것으로, 한 팀이 동일한 파일을 동시에 변경할 수 있습니다.

버전 관리 시스템은 일반적으로 독립 실행형 응용 프로그램으로 실행되지만, 버전 관리는 워드프로세서 및 스프레드시트, 협업 ^[3]웹 문서, 컨텐츠 관리 시스템(Wikipedia 페이지 이력 등) 등 다양한 유형의 소프트웨어에도 포함되어 있습니다.리비전 제어를 통해 문서를 이전 리비전으로 되돌릴 수 있습니다.이러한 리비전은 편집자가 서로의 편집을 추적하고 오류를 수정하며 Wiki에서 반달리즘 및 스팸을 방지하는 데 매우 중요합니다.

개요

컴퓨터 소프트웨어 엔지니어링에서 리비전 제어는 소스 코드의 변경을 추적하고 제어하는 모든 종류의 작업입니다.소프트웨어 개발자는 때때로 리비전 제어 소프트웨어를 사용하여 문서 및 구성 파일 및 소스 코드를 유지관리합니다.

팀이 소프트웨어를 설계, 개발 및 도입할 때 동일한 소프트웨어의 여러 버전이 서로 다른 사이트에 배치되고 소프트웨어 개발자가 동시에 업데이트 작업을 수행하는 것이 일반적입니다.소프트웨어의 버그나 기능은 특정 버전에만 존재하는 경우가 많습니다(일부 문제는 수정되고 프로그램 개발 시 다른 문제가 도입되기 때문입니다).따라서 버그를 특정하고 수정하기 위해서는 다른 버전의 소프트웨어를 검색하여 실행하여 문제가 발생하고 있는 버전을 판별하는 것이 매우 중요합니다.또, 2개의 버전의 소프트웨어를 동시에 개발할 필요가 있는 경우도 있습니다.예를 들어, 한쪽 버전은 버그가 수정되어 있지만 새로운 기능(브런치)이 없는 반면, 다른 한쪽 버전은 새로운 기능이 동작하는(트렁크) 버전입니다.

가장 간단한 수준에서 개발자는 프로그램의 다른 버전의 복사본을 여러 개 보관하고 적절한 레이블을 지정할 수 있습니다.이 간단한 접근법은 많은 대규모 소프트웨어 프로젝트에서 사용되어 왔습니다.이 방법은 작동하지만 거의 동일한 프로그램 복사본을 유지해야 하므로 비효율적입니다.이것은 개발자의 많은 자기 훈련이 필요하며 종종 실수를 초래합니다.코드 베이스가 같기 때문에, 일련의 개발자에게 읽기-쓰기-실행 권한을 부여해야 합니다.이 때문에 코드 베이스가 손상되지 않도록 권한을 관리하는 사용자의 부담이 가중되어 복잡성이 증가합니다.그 결과 리비전 제어 프로세스의 일부 또는 전부를 자동화하는 시스템이 개발되었습니다.이것에 의해, 버전 관리 순서의 대부분이 백그라운드에서 숨겨집니다.

또한 소프트웨어 개발, 법률 및 비즈니스 프랙티스 및 기타 환경에서는 팀원들이 지리적으로 분산되어 서로 다른 이해관계를 추구할 수 있는 단일 문서 또는 코드 조각이 편집되는 것이 점점 더 일반화되고 있습니다.문서나 코드의 변경을 추적해, 그 소유권을 설명하는 고도의 리비전 제어는, 그러한 상황에서는 지극히 도움이 되거나, 불가결할 수도 있습니다.

리비전 제어에서는 일반적으로 에 저장되어 있는 설정 파일 등의 변경도 추적할 수 있습니다./etc또는/usr/local/etc를 참조해 주세요.이를 통해 시스템 관리자는 변경을 쉽게 추적할 수 있으며 필요에 따라 이전 버전으로 롤백할 수 있습니다.

역사

IBM의 OS/360 IEBUPDTE 소프트웨어 업데이트 도구는 1962년으로 거슬러 올라갑니다. 이는 버전 관리 시스템 도구의 선구자일 것입니다.소스 코드 제어를 위해 설계된 전체 시스템은 1972년에 시작되었으며, 동일한 시스템에 대한 소스 코드 제어 시스템(OS/360)입니다.1975년 12월 4일 발표된 소스 코드 제어 시스템의 도입은 역사적으로 최초의 고의적인 개정 제어 ^[4]시스템임을 암시한다.RCS는 ^[5]그 직후에 네트워크 버전의 Concurrent Versions System을 도입했습니다.Concurrent Versions System 이후의 다음 세대는 Subversion에 ^[6]의해 지배되었고,^[7] Git과 같은 분산 리비전 제어 툴의 등장이 뒤따랐다.

구조.

리비전 제어는 시간 경과에 따른 데이터 세트의 변경을 관리합니다.이러한 변경은 다양한 방법으로 구성될 수 있습니다.

대부분의 경우 데이터는 파일이나 문서와 같은 많은 개별 항목의 집합으로 간주되며 개별 파일에 대한 변경 내용이 추적됩니다.이는 개별 파일에 대한 직관과 일치하지만 파일 이름 변경, 분할 또는 병합 중 등 ID 변경 시 문제가 발생합니다.따라서 Git과 같은 일부 시스템은 데이터 전체에 대한 변경을 고려하고 있으며, 이는 단순한 변경에는 덜 직관적이지만 더 복잡한 변경을 단순화합니다.

체크 아웃을 통해 리비전 관리 중인 데이터를 수정한 경우, 일반적으로 리비전 관리 시스템(저장소)에 바로 반영되지 않고, 체크 인 또는 커밋해야 합니다.외부 리비전 제어 복사는 "작업 복사본"이라고 합니다.간단한 예로서 컴퓨터 파일을 편집할 때 편집 프로그램에 의해 메모리에 저장되는 데이터는 저장에 의해 커밋되는 작업 복사본입니다.구체적으로는 문서를 인쇄해 손으로 편집한 뒤 나중에 수동으로 변경 내용을 입력해 저장할 수 있다.소스 코드 제어의 경우 작업 복사본은 특정 리비전의 모든 파일의 복사본으로 일반적으로 개발자의 ^{[note 1]}컴퓨터에 로컬로 저장됩니다. 이 경우 파일을 저장하면 작업 복사본만 변경되며 저장소에 체크인하는 것은 별도의 단계입니다.

여러 사용자가 단일 데이터 세트 또는 문서에서 작업하는 경우 데이터의 분기(작업 복사본)를 암묵적으로 생성하므로 다음과 같이 병합 문제가 발생합니다.간단한 공동 작업 문서 편집의 경우, 파일 잠금을 사용하거나 다른 사용자가 작업 중인 동일한 문서에서 작업하지 않도록 함으로써 이러한 문제를 방지할 수 있습니다.

리비전 제어 시스템은 대부분의 경우 중앙 집중식으로 관리되며, 이 중앙 저장소를 참조하여 하나의 권한 있는 데이터스토어, 저장소, 체크아웃 및 체크인을 수행합니다.또는 분산 리비전 제어에서는 단일 저장소가 권한이 없으며 데이터를 모든 저장소로 체크아웃 및 체크인할 수 있습니다.다른 리포지토리에 체크인하는 경우 이는 병합 또는 패치로 해석됩니다.

그래프 구조

그래프 이론의 관점에서 리비전은 일반적으로 가지가 분리된 발전선(트렁크)으로 간주되며, 하나 이상의 평행한 발전선(트렁크)이 트렁크에서 분기하는 것으로 시각화된다.실제로는 구조가 더 복잡하여 방향 비순환 그래프를 형성하지만, 많은 목적을 위해 "합이 있는 나무"는 적절한 근사치이다.

리비전은 시간 경과에 따라 순차적으로 발생하므로 리비전 번호 ^{[note 2]}또는 타임스탬프별로 정렬할 수 있습니다.리비전은 과거 리비전을 기반으로 하지만 "기존 텍스트를 모두 삭제하고 새 텍스트를 삽입"과 같은 이전 리비전을 대체하거나 완전히 대체할 수 있습니다.가장 간단한 경우 분기 또는 취소 없이 각 리비전은 직전 리비전만을 기반으로 하며 단일 최신 버전인 "HEAD" 리비전 또는 팁으로 단순한 라인을 형성합니다.그래프 이론에서 각 수정사항을 점으로 그리고 각 "파생 수정사항" 관계를 화살표로 그리는 것은 선형 그래프입니다(기존에는 시간과 같은 방향을 가리키고 있습니다).분기가 존재하기 때문에 미래의 여러 리비전이 과거 리비전 또는 취소에 기초하고 있기 때문에 리비전은 직전 리비전에 의존할 수 있습니다.그 결과 그래프는 대신 방향 트리(각 노드에는 여러 개의 하위 노드가 있을 수 있음)로, 하위 노드가 없는 리비전에 대응하는 여러 힌트가 있습니다('최신 revi').각 지점의 sion)^{[note 3]}을 클릭합니다.원칙적으로 트리에 바람직한 힌트("메인" 최신 리비전)가 있을 필요는 없습니다.다양한 리비전만 있으면 됩니다만, 실제로는 힌트 중 하나가 일반적으로 HEAD로 식별됩니다.새로운 리비전이 HEAD에 기반하면 새로운 HEAD로 식별되거나 새로운 브랜치로 ^{[note 4]}간주됩니다.시작부터 HEAD까지의 리비전 리스트(그래프 이론에서는 이전과 같이 선형 그래프를 형성하는 트리 내의 고유 경로)는 트렁크 또는 메인라인입니다.^{[note 5]}반대로 리비전이 여러 이전 리비전에 기반할 수 있는 경우(노드에 여러 부모 리비전이 있을 수 있는 경우), 결과 프로세스는 머지라고 불리며 리비전 제어의 가장 복잡한 측면 중 하나입니다.이것은, 복수의 브랜치(대개 2개, 가능한 브랜치)에서 변경이 발생했을 경우에 가장 많이 발생합니다.이 브랜치들은 양쪽의 변경을 포함한1개의 브랜치로 통합됩니다.이러한 변경이 겹칠 경우 병합이 어렵거나 불가능할 수 있으며 수동 개입 또는 개서가 필요할 수 있습니다.

병합이 존재하는 경우 노드가 여러 개의 부모를 가질 수 있으므로 결과 그래프는 더 이상 트리가 아니라 루트 방향 비순환 그래프(DAG)가 됩니다.그래프는 부모가 항상 과거로 돌아가기 때문에 비순환적이며 가장 오래된 버전이 있기 때문에 루트가 됩니다.트렁크가 있는 경우 브런치로부터의 Marge는 트리의 "외부"로 간주할 수 있습니다.브런치 변경은 패치로 패키지화되어 HEAD(트렁크)에 적용되며 브런치를 명시적으로 참조하지 않고 새로운 리비전을 작성하고 트리 구조를 유지합니다.따라서 버전 간의 실제 관계는 DAG를 형성하지만 이는 트리 플러스 머지로 간주할 수 있으며 트렁크 자체는 회선입니다.

분산 리비전 제어에서는 여러 개의 리포지토리가 있는 경우 단일 원본 버전(트리의 루트)에 기반할 수 있지만 원래 루트가 있을 필요는 없습니다.따라서 예를 들어 두 사람이 개별적으로 프로젝트를 시작하는 경우 각 저장소에 대해 별도의 루트(최신 버전)만 있을 뿐입니다.마찬가지로 데이터를 교환하거나 병합하는 여러 데이터 세트(복수의 프로젝트)가 존재하는 경우 단일 루트는 존재하지 않습니다.단, 단순성을 위해 한쪽 프로젝트는 프라이머리 프로젝트, 다른 한쪽은 세컨더리로 간주할 수 있습니다.단, 자체 리비전 이력이 있거나 없는 첫 번째 프로젝트에 병합됩니다.

특화된 전략

엔지니어링 리비전 제어는 초기 설계도 또는 블루라인의^{[citation needed]} 리비전 추적을 기반으로 한 정식 프로세스에서 개발되었습니다.이 제어 시스템은 설계의 개발 과정에서 엔지니어링 막다른 골목에 도달한 경우에 설계의 초기 상태로의 복귀를 암묵적으로 허용했다.변경 내용을 추적하기 위해 수정 테이블이 사용되었습니다.또한 도면의 수정된 영역은 구름형 수정판을 사용하여 강조 표시되었습니다.

버전 관리는 비즈니스와 법률에 널리 퍼져 있습니다.사실, "계약 레드라인"과 "법률 블랙라인"은 개정 ^[8]통제의 초기 형태 중 일부이며, 여전히 다양한 수준의 정교함으로 비즈니스와 법률에 채용되고 있다.CAD 파일의 변경 사항을 전자적으로 추적하는 데 가장 정교한 기술이 사용되기 시작하고 있습니다(제품 데이터 관리 참조). 이는 기존의 리비전 ^{[citation needed]}제어의 "수동" 전자 구현을 대체하는 것입니다.

소스 관리 모델

기존의 리비전 제어 시스템은 모든 리비전 제어 기능이 공유 서버에서 실행되는 중앙 집중식 모델을 사용합니다.두 개발자가 동시에 동일한 파일을 변경하려고 하면 액세스를 관리하는 방법이 없을 경우 개발자는 서로의 작업을 덮어쓰게 될 수 있습니다.중앙 집중식 리비전 제어 시스템은 파일 잠금과 버전 병합의 두 가지 "소스 관리 모델" 중 하나로 이 문제를 해결합니다.

원자 작전

동작이 중단되어도 시스템이 일관된 상태로 유지되면 동작은 원자성이 됩니다.이 점에서 보통 커밋 조작이 가장 중요합니다.커밋은 수정사항 제어 시스템에 변경사항 그룹을 최종화하고 모든 사용자가 사용할 수 있도록 지시합니다.모든 리비전 제어 시스템에 아토믹 커밋이 있는 것은 아닙니다.Concurrent Versions System에는 이 ^[9]기능이 없습니다.

파일 잠금

"동시 액세스" 문제를 방지하는 가장 간단한 방법은 한 번에 한 명의 개발자만 해당 파일의 중앙 "리포지토리" 복사본에 대한 쓰기 액세스 권한을 갖도록 파일을 잠그는 것입니다.한 개발자가 파일을 "체크아웃"하면 다른 개발자는 해당 파일을 읽을 수 있지만, 해당 개발자가 업데이트된 버전을 "체크인"하거나 체크아웃을 취소할 때까지 다른 누구도 해당 파일을 변경할 수 없습니다.

파일 잠금에는 장점과 단점이 있습니다.사용자가 대용량 파일(또는 파일 그룹)의 많은 섹션을 급격하게 변경할 때 어려운 병합 충돌로부터 어느 정도 보호할 수 있습니다.파일을 너무 오랫동안 독점적으로 잠그면 다른 개발자가 리비전 제어 소프트웨어를 무시하고 로컬로 파일을 변경하려는 유혹을 받게 되고, 다른 변경사항이 최종적으로 체크인될 때 수동으로 병합하기가 어려워질 수 있습니다.대규모 조직에서는 개발자가 프로젝트 간에 이동할 때 파일을 "체크아웃"한 상태로 두고 잠근 채 잊어버릴 수 있습니다.이러한 툴을 사용하면 파일을 체크아웃한 사용자를 쉽게 확인할 수도 있고 그렇지 않을 수도 있습니다.

버전 병합

대부분의 버전 관리 시스템에서는 여러 개발자가 동시에 동일한 파일을 편집할 수 있습니다.중앙 저장소에 대한 변경 사항을 "체크인"하는 첫 번째 개발자는 항상 성공합니다.시스템은 중앙 저장소에 추가 변경 사항을 병합하고 다른 개발자가 체크인할 때 첫 번째 개발자의 변경 사항을 보존할 수 있는 기능을 제공할 수 있습니다.

두 파일을 병합하는 작업은 매우 정교한 작업이 될 수 있으며, 일반적으로 텍스트 파일과 같이 데이터 구조가 단순한 경우에만 가능합니다.두 이미지 파일이 병합되면 이미지 파일이 전혀 생성되지 않을 수 있습니다.코드를 체크인하는 두 번째 개발자는 변경 내용이 호환되는지, 그리고 병합 작업이 파일 내에 자체 논리 오류를 발생시키지 않는지 확인하기 위해 병합에 주의해야 합니다.이러한 문제는 파일 형식에 특정 병합 플러그인을 사용할 수 없는 경우를 제외하고 자동 또는 반자동 병합 작업의 가용성을 주로 단순 텍스트 기반 문서로 제한합니다.

예약된 편집 개념은 병합 기능이 있는 경우에도 파일을 명시적으로 잠그고 전용 쓰기 액세스를 수행할 수 있는 선택적 수단을 제공할 수 있습니다.

기준선, 라벨 및 태그

대부분의 리비전 제어 툴에서는 스냅샷 식별 작업('프로젝트 라벨') 또는 스냅샷 기록('기준 X로 테스트')을 나타내는 유사한 용어(기준선, 라벨, 태그) 중 하나만 사용합니다.일반적으로 문서 또는 토론에서는^{[citation needed]} 기준선, 라벨 또는 태그 중 하나만 사용되며 동의어로 간주할 수 있습니다.

대부분의 프로젝트에서 게시된 릴리스, 지점 또는 마일스톤을 나타내는 데 사용되는 스냅샷과 같이 일부 스냅샷이 다른 스냅샷보다 더 중요합니다.

기준선과 라벨 또는 태그 중 하나를 동일한 맥락에서 함께 사용하는 경우 라벨과 태그는 일반적으로 스냅샷을 식별하거나 기록하는 도구 내의 메커니즘을 의미하며, 기준선은 지정된 라벨 또는 태그의 중요도가 증가했음을 나타냅니다.

구성 관리에 대한 공식적인 논의에서는 대부분 기준선이라는 용어를 사용합니다.

분산 리비전 제어

분산 리비전 제어 시스템(DRCS)은 일원화된 시스템의 클라이언트-서버 접근 방식과 달리 피어 투 피어 접근 방식을 취합니다.클라이언트가 동기화하는 단일 중앙 저장소가 아니라 각 피어의 코드 기반 작업 복사본이 진정한 저장소입니다.^[10]분산 리비전 제어는 피어 간에 패치(변경 세트)를 교환하여 동기화를 수행합니다.따라서 중앙 집중식 시스템과는 다음과 같은 몇 가지 중요한 차이가 있습니다.

• 기본적으로는 코드베이스의 표준 참조 복사본은 존재하지 않으며 작업 복사본만 존재합니다.
• 커밋, 이력 표시, 변경 되돌리기 등의 일반적인 조작은 중앙 ^{[1]: 7} 서버와 통신할 필요가 없기 때문에 고속입니다.

커뮤니케이션은 다른 피어(peer)와의 사이에서 변경 사항을 밀고 당기거나 할 때만 필요합니다.

• 각 작업 복사본은 코드 기반 및 변경 이력의 원격 백업으로 효과적으로 기능하여 데이터 ^{[1]: 4} 손실로부터 본질적으로 보호합니다.

통합

보다 고도의 리비전 제어 툴 중 일부는 다른 많은 기능을 제공하여 다른 툴 및 소프트웨어 엔지니어링 프로세스와의 보다 긴밀한 통합을 가능하게 합니다.플러그인은 Oracle JDeveloper, IntelliJ IDEA, Eclipse, Visual Studio, Delphi, NetBeans IDE, Xcode 및 GNU Emacs(vc.el 경유) 등의 IDE에서 자주 사용할 수 있습니다.고급 연구 프로토타입은 적절한 커밋 ^[11]메시지를 생성하지만 커밋 메시지는 프로젝트의 ^[12]관습과 특성에 따라 크게 달라지기 때문에 이미 큰 이력을 가진 프로젝트에서만 작동합니다.

공통 용어

용어는 시스템에 따라 다를 수 있지만 일반적인 용어의 일부는 다음과 같습니다.^[13]

베이스라인

이후에 변경할 수 있는 문서 또는 원본 파일의 승인된 수정본입니다.기준선, 레이블 및 태그를 참조하십시오.

을 탓하다

특정 행을 마지막으로 수정한 작성자 및 수정본 검색.

분점

버전 관리 하에 있는 파일 세트는 분기 또는 분기할 수 있으며, 그 시점부터 이들 파일의 두 복사본이 서로 독립적으로 다른 속도 또는 다른 방식으로 개발될 수 있습니다.

바꾸다

변경(또는 diff 또는 delta)은 버전 제어 하에 있는 문서에 대한 특정 수정을 나타냅니다.변경으로 간주되는 수정의 세밀도는 버전 제어 시스템에 따라 다릅니다.

리스트 변경

아토믹 멀티체인지 커밋, 변경 리스트(또는 CL), 변경 세트, 갱신 또는 패치가 있는 많은 버전 제어 시스템에서는 단일 커밋으로 이루어진 변경 세트를 식별합니다.또, 소스 코드의 시퀀셜 뷰를 나타내, 특정의 체인지 리스트 ID 로서 소스를 조사할 수 있습니다.

체크아웃

체크아웃(또는 공동)은 저장소에서 로컬 작업 복사본을 만드는 것입니다.사용자는 특정 리비전을 지정하거나 최신 버전을 얻을 수 있습니다.'체크아웃'이라는 용어는 작업 복사본을 설명하는 명사로도 사용될 수 있습니다.공유 파일 서버에서 파일을 체크아웃하면 다른 사용자가 편집할 수 없습니다.호텔이라고 생각해 보세요. 체크아웃을 하면 더 이상 편의시설을 이용할 수 없습니다.

클론

복제는 다른 저장소에서 리비전을 포함하는 저장소를 생성하는 것을 의미합니다.이는 빈(새로 초기화된) 저장소로 푸시 또는 풀링하는 것과 같습니다.명사로서 두 개의 리포지토리가 동기화되어 있고 동일한 리비전이 포함되어 있으면 클론이라고 할 수 있습니다.

커밋(noun)

'commit' 또는 'revision'(SVN)은 저장소에 적용되는 수정 사항입니다.

커밋(동사)

커밋(체크인, CI, 또는 드물게 설치, 제출 또는 기록)은 작업 복사본에서 변경한 내용을 저장소로 다시 쓰거나 병합하는 것입니다.커밋에는 메타데이터(통상은 작성자 정보 및 변경을 설명하는 커밋메시지가 포함됩니다.

갈등.

서로 다른 당사자가 동일한 문서를 변경하고 시스템이 변경 사항을 조정할 수 없는 경우 충돌이 발생합니다.사용자는 변경을 조합하거나 다른 변경을 선택하여 경합을 해결해야 합니다.

델타 압축

대부분의 리비전 제어 소프트웨어는 델타 압축을 사용합니다. 델타 압축은 연속된 파일 버전 간의 차이만 유지합니다.이를 통해 다양한 버전의 파일을 보다 효율적으로 저장할 수 있습니다.

동적 스트림

일부 또는 모든 파일 버전이 상위 스트림 버전을 미러링하는 스트림입니다.

내보내기

내보내기란 저장소에서 파일을 가져오는 작업입니다.작업 복사본에서 사용되는 버전 제어 메타데이터가 없는 클린 디렉토리 트리를 만든다는 점을 제외하면 체크아웃과 유사합니다.예를 들어 내용을 게시하기 전에 자주 사용됩니다.

가지고 오다

당김을 참조해 주세요.

전진 통합

메인 트렁크에서 이루어진 변경을 개발(기능 또는 팀) 브랜치로 Marge하는 프로세스.

머리

tip이라고도 불리며 트렁크 또는 브랜치에 대한 최신 커밋을 가리킵니다.트렁크 및 각 브랜치에는 자체 헤드가 있지만 ^[14]HEAD는 트렁크를 나타낼 때 느슨하게 사용되는 경우가 있습니다.

수입품

Import는 로컬디렉토리 트리(현재는 작업 복사본이 아님)를 저장소에 처음으로 복사하는 작업입니다.

초기화

비어 있는 새 저장소를 만듭니다.

인터리브 삼각주

일부 리비전 제어 소프트웨어에서는 델타 압축을 사용하는 것보다 텍스트 기반 파일의 이력을 더 효율적으로 저장할 수 있는 방법인 인터리브 델타(Interleaved Delta)를 사용합니다.

라벨.

태그 참조.

잠금

개발자가 파일을 잠그면 해당 파일이 잠금 해제될 때까지 다른 사용자가 해당 파일을 업데이트할 수 없습니다.잠금 기능은 버전 관리 시스템 또는 개발자 간의 비공식 통신(소셜 잠금이라고도 함)을 통해 지원됩니다.

메인라인

트렁크와 비슷하지만 각 브랜치에는 메인라인이 있을 수 있습니다.

머지

병합 또는 통합은 파일 또는 파일 집합에 두 가지 변경 사항이 적용되는 작업입니다.예를 들어 다음과 같습니다.

• 파일 세트를 작업 중인 사용자가 작업 복사본을 다른 사용자가 ^[15]변경한 내용과 업데이트 또는 동기화하여 저장소에 체크인합니다.
• 사용자는 파일이 체크아웃된 후 다른 사용자가 업데이트한 파일을 체크인하려고 하면 리비전 제어 소프트웨어가 자동으로 파일을 Marge합니다(일반적으로 자동 Marge를 계속할 것인지 사용자에게 프롬프트한 후, 경우에 따라서는 Marge가 명확하고 합리적으로 해결될 수 있는 경우에만 해당).
• 브런치가 생성되고 파일 내의 코드가 독립적으로 편집되며 업데이트된 브런치가 나중에 단일 통합 트렁크에 통합됩니다.
• 파일 세트가 분기됩니다.이러한 문제는 분기 전에 한 분기에서 해결된 후 다른 분기에 병합됩니다(이러한 선택적 병합 유형은 이전 경우 완전한 병합과 구별하기 위해 체리 픽이라고도 합니다).

촉진하다

제어가 덜 된 위치에서 보다 제어가 잘된 위치로 파일 내용을 복사하는 작업입니다.예를 들어 사용자의 작업 공간에서 저장소로, 스트림에서 ^[16]상위 저장소로의 스트림 등이 있습니다.

당겨, 밀어

한 저장소에서 다른 저장소로 리비전을 복사합니다.풀은 수신 리포지토리에 의해 시작되며 푸시는 소스에 의해 시작됩니다.Fetch는 pull의 동의어 또는 pull에 이어 업데이트로 사용되는 경우가 있습니다.

풀 리퀘스트

개발자가 다른 사용자에게 "푸시된" 변경 사항을 병합하도록 요청합니다.

저장소

저장소(또는 "repo")는 파일의 현재 및 기록 데이터를 저장하는 곳으로, 대부분의 경우 서버에 저장됩니다.가끔 창고라고도 불리지

해결하다

동일한 문서에 대한 다른 변경 사항 간의 충돌을 해결하기 위해 사용자가 개입하는 행위입니다.

리버스 인테그레이션

다른 팀을 버전시스템의 메인트렁크로 Marge하는 프로세스는 브랜치됩니다.

리비전

또한 버전: 버전은 형식이 변경된 것입니다.SVK에서 리비전은 저장소 내 트리 전체의 시점 상태를 말합니다.

공유하다

하나의 파일 또는 폴더를 여러 분기에서 동시에 사용할 수 있도록 하는 행위입니다.공유 파일이 한 분기에서 변경되면 다른 분기에서 변경됩니다.

개울.

이러한 다른 컨테이너와 알려진 관계가 있는 분기된 파일의 컨테이너입니다.스트림은 계층을 형성합니다.각 스트림은 부모 스트림에서 다양한 속성(버전, 네임스페이스, 워크플로우 규칙, 사용자 등)을 상속할 수 있습니다.

태그

태그 또는 라벨은 많은 파일에 걸쳐 일관된 중요한 시간 스냅샷을 나타냅니다.이 시점에서 이들 파일은 모두 사용하기 쉽고 의미 있는 이름 또는 리비전 번호로 태그가 붙을 수 있습니다.기준선, 레이블 및 태그를 참조하십시오.

트렁크.

브랜치가 아닌 독자적인 개발 라인(Baseline, Mainline 또는^[17][18] Master라고도 함)

갱신하다

업데이트(또는 동기화, 동기화)는 저장소(예: 다른 사용자가)에서 수행한 변경 사항을 로컬 작업 복사본에 병합합니다.업데이트는 일부 CM 툴(CM+, PLS, SMS)에서 변경 패키지의 개념을 나타내는 용어이기도 합니다(changelist 참조).리비전 관리 시스템의 체크 아웃과 같은 의미로 각 저장소에 작업 복사본이 1개씩 있어야 합니다(분산형 시스템에서 공통).

잠금 해제

잠금 해제

작업용 복사

작업 복사본은 특정 시간 또는 개정 시 저장소에서 파일의 로컬 복사본입니다.저장소의 파일에 대해 수행된 모든 작업은 처음에는 작업 복사본에서 수행되므로 이름이 지정됩니다.개념적으로는 샌드박스입니다.

「 」를 참조해 주세요.

메모들

레퍼런스

외부 링크

• 를 클릭합니다"Visual Guide to Version Control", Better explained.
• Sink, Eric, "Source Control", SCM (how‐to). 버전 관리의 기본입니다.