본문으로 이동

버전 관리

위키백과, 우리 모두의 백과사전.

버전 관리(영어: version control, revision control) 또는 소스 관리(영어: source control)[1] 혹은 소스 코드 관리(영어: source code management)는 컴퓨터 파일, 주로 소스 코드 텍스트 파일이지만 일반적으로는 모든 유형의 파일의 이력에 있는 다양한 버전을 제어, 조직 및 추적하는 소프트웨어 공학 실무이다.

버전 관리는 소프트웨어 구성 관리의 구성 요소이다.[1]

버전 관리 시스템은 버전 관리를 자동화하는 소프트웨어 도구이다. 또는 워드 프로세서, 스프레드시트, 협업 웹 문서,[2] 그리고 위키백과의 문서 역사와 같은 저작물 관리 시스템의 기능으로 버전 관리가 내장되기도 한다.

버전 관리는 이전 버전을 확인하고 파일을 이전 버전으로 되돌리는 옵션을 포함한다.

개요

[편집]

팀이 소프트웨어를 개발할 때 동일한 소프트웨어의 여러 버전을 전개하고, 서로 다른 개발자가 하나 이상의 버전을 동시에 작업하는 것은 흔한 일이다. 버그나 소프트웨어의 기능은 프로그램이 개발됨에 따라 특정 문제의 수정이나 새로운 문제의 도입으로 인해 특정 버전에만 존재하는 경우가 많다. 따라서 버그를 찾고 수정하기 위해 소프트웨어의 서로 다른 버전을 검색하고 실행하여 어느 버전에서 문제가 발생하는지 확인하는 것이 매우 중요하다. 또한 버그는 수정되었지만 새로운 기능은 추가되지 않은 버전(브랜치)과 새로운 기능이 작업 중인 버전(트렁크)처럼 두 가지 버전의 소프트웨어를 동시에 개발해야 할 수도 있다.

가장 단순한 수준에서 개발자는 단순히 프로그램의 여러 버전에 대한 사본을 유지하고 적절하게 라벨을 붙일 수 있다. 이 간단한 접근 방식은 많은 대규모 소프트웨어 프로젝트에서 사용되었다. 이 방법이 효과적일 수는 있지만, 프로그램의 거의 동일한 사본을 많이 유지해야 하므로 비효율적이다. 이는 개발자 측에서 많은 자제력을 요구하며 종종 실수를 유발한다. 코드 베이스가 동일하기 때문에 개발자 그룹에 읽기-쓰기-실행 권한을 부여해야 하며, 이로 인해 코드 베이스가 손상되지 않도록 권한을 관리해야 하는 압박이 더해져 복잡성이 가중된다. 결과적으로 리비전 관리 과정의 일부 또는 전부를 자동화하는 시스템이 개발되었다. 이는 대부분의 운영 단계를 추상화(일반 사용자에게 숨김)한다.

게다가 소프트웨어 개발, 법률 및 비즈니스 관행, 기타 환경에서 단일 문서나 코드 조각을 지리적으로 분산되어 있고 서로 다르거나 심지어 상반된 이해관계를 추구할 수 있는 팀이 편집하는 경우가 점점 더 흔해지고 있다. 문서 및 코드 변경 사항의 소유권을 추적하고 설명하는 정교한 리비전 관리는 이러한 상황에서 매우 도움이 되거나 없어서는 안 될 요소일 수 있다.

리비전 관리는 유닉스 시스템의 `/etc` 또는 `/usr/local/etc`에 일반적으로 저장되는 것과 같은 구성 파일의 변경 사항도 추적할 수 있다. 이는 시스템 관리자가 변경 사항을 쉽게 추적하고 필요할 경우 이전 버전으로 되돌릴 수 있는 또 다른 방법을 제공한다.

많은 버전 관리 시스템은 파일의 버전을 버전 번호, 버전, 리비전 번호, 리비전 또는 리비전 레벨이라고 불리는 숫자나 문자로 식별한다. 예를 들어 파일의 첫 번째 버전은 버전 1일 수 있다. 파일이 변경되면 다음 버전은 2가 된다. 각 버전은 타임스탬프 및 변경을 수행한 사람과 연결된다. 리비전은 비교, 복원될 수 있으며, 일부 유형의 파일에서는 병합될 수 있다.[3]

역사

[편집]

IBM의 OS/360 IEBUPDTE 소프트웨어 업데이트 도구는 1962년으로 거슬러 올라가며, 사실상 버전 관리 시스템 도구의 선구자이다. IBM 360/370 설치에서 많이 사용된 두 가지 소스 관리 및 버전 관리 패키지는 The Librarian과 Panvalet이었다.[4][5]

소스 코드 제어를 위해 설계된 완전한 시스템은 1972년에 시작된 소스 코드 제어 시스템(SCCS)으로, 역시 OS/360용이었다. 1975년 12월 4일에 출판된 SCCS 사용자 매뉴얼, 특히 서문은 이것이 최초의 의도적인 리비전 관리 시스템임을 암시했다.[6] 리비전 컨트롤 시스템(RCS)이 1982년에 뒤를 이었고[7], 이후 CVS (버전 관리 시스템)(CVS)가 RCS에 네트워크 및 동시 개발 기능을 추가했다. CVS 이후 지배적인 후계자는 서브버전이었으며[8], 그 뒤를 이어 깃과 같은 분산 버전 관리 도구가 부상했다.[9]

구조

[편집]

리비전 관리는 시간이 지남에 따라 데이터 세트에 대한 변경 사항을 관리한다. 이러한 변경 사항은 다양한 방식으로 구조화될 수 있다.

종종 데이터는 파일이나 문서와 같은 많은 개별 항목의 모음으로 간주되며 개별 파일에 대한 변경 사항이 추적된다. 이는 파일을 분리하여 유지한다는 개념과 일치하지만, 파일 이름이 변경되거나 분할 또는 병합될 때 발생하는 식별자 변경 시 문제가 발생한다. 따라서 깃과 같은 일부 시스템은 대신 데이터 변경을 전체적으로 고려하는데, 이는 간단한 변경에는 직관적이지 않지만 더 복잡한 변경을 단순화한다.

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

여러 사람이 단일 데이터 세트나 문서를 작업하는 경우 암묵적으로 데이터의 브랜치(작업 사본 내)를 생성하는 것이며, 따라서 아래에서 논의하는 병합 문제가 발생한다. 간단한 협업 문서 편집의 경우, 파일 잠금을 사용하거나 다른 사람이 작업 중인 문서를 편집하지 않음으로써 이를 방지할 수 있다.

리비전 관리 시스템은 종종 중앙 집중식으로, 단일 권한 데이터 저장소인 저장소를 가지며 체크아웃과 체크인은 이 중앙 저장소를 참조하여 수행된다. 또는 분산 버전 관리에서는 권한이 있는 단일 저장소가 없으며 데이터는 모든 저장소에서 체크아웃 및 체크인될 수 있다. 다른 저장소로 체크인할 때 이는 병합 또는 패치로 해석된다.

그래프 구조

[편집]
리비전 관리 프로젝트의 예시 이력 그래프. 트렁크는 녹색, 브랜치는 노란색으로 표시됨. 병합(빨간색 화살표)이 존재하기 때문에 그래프는 트리가 아니다.

그래프 이론의 관점에서 리비전은 일반적으로 개발 라인(트렁크)과 거기에서 파생된 브랜치로 생각되며, 트렁크에서 분기되는 하나 이상의 평행한 개발 라인("브랜치의 메인라인")으로 시각화되는 유향 트리를 형성한다. 실제 구조는 더 복잡하여 유향 비순환 그래프를 형성하지만, 많은 목적에 있어 "병합이 있는 트리"가 적절한 근사치이다.

리비전은 시간이 지남에 따라 순차적으로 발생하므로 리비전 번호나 타임스탬프로 순서를 정할 수 있다.[note 2] 리비전은 과거 리비전에 기반을 두지만, "모든 기존 텍스트를 삭제하고 새 텍스트를 삽입"하는 것과 같이 이전 리비전을 크게 또는 완전히 대체하는 것도 가능하다. 브랜치나 취소가 없는 가장 간단한 경우, 각 리비전은 직전 리비전에만 기반하며, 이는 "HEAD" 리비전 또는 팁이라는 단일 최신 버전을 가진 단순한 라인을 형성한다. 그래프 이론 용어로 각 리비전을 점으로, 각 "파생 리비전" 관계를 화살표(관습적으로 시간과 같은 방향인 과거에서 미래로 향함)로 그리면 이것은 선형 그래프이다. 브랜치가 있어 여러 미래 리비전이 과거 리비전에 기반을 두거나, 취소가 있어 리비전이 직전 리비전보다 더 오래된 리비전에 의존할 수 있는 경우, 결과 그래프는 대신 유향 트리가 되며(각 노드는 하나 이상의 자식을 가질 수 있음), 자식이 없는 리비전("각 브랜치의 최신 리비전")에 해당하는 여러 팁을 가진다.[note 3] 원칙적으로 결과 트리에는 선호되는 팁("메인" 최신 리비전)이 없어도 되지만—단지 다양한 리비전이 있을 뿐—실제로는 한 팁이 일반적으로 HEAD로 식별된다. 새 리비전이 HEAD에 기반을 두면 새로운 HEAD로 식별되거나 새로운 브랜치로 간주된다.[note 4] 시작부터 HEAD까지의 리비전 목록(그래프 이론 용어로, 이전과 같이 선형 그래프를 형성하는 트리의 유일한 경로)은 트렁크 또는 메인라인이다.[note 5] 반대로, 리비전이 둘 이상의 이전 리비전에 기반을 둘 수 있을 때(노드가 둘 이상의 부모를 가질 수 있을 때), 그 결과 과정을 머지라고 하며, 이는 버전 관리의 가장 복잡한 측면 중 하나이다. 이는 대개 여러 브랜치(보통 두 개지만 더 많을 수도 있음)에서 변경 사항이 발생하여 두 변경 사항을 모두 포함하는 단일 브랜치로 병합될 때 발생한다. 이러한 변경 사항이 겹치면 병합하기 어렵거나 불가능할 수 있으며 수동 개입이나 재작성이 필요할 수 있다.

병합이 존재하면 노드가 여러 부모를 가질 수 있으므로 결과 그래프는 더 이상 트리가 아니라 루트가 있는 유향 비순환 그래프(DAG)이다. 부모는 항상 시간상 과거이므로 그래프는 비순환적이고, 가장 오래된 버전이 있으므로 루트가 있다. 트렁크가 있다고 가정하면 브랜치에서의 병합은 트리에서 "외부"적인 것으로 간주될 수 있다. 브랜치의 변경 사항은 패치로 패키지화되어 HEAD(트렁크의)에 적용되며, 브랜치에 대한 명시적인 참조 없이 트리의 구조를 보존하는 새 리비전을 생성한다. 따라서 버전 간의 실제 관계는 DAG를 형성하지만, 이는 트리와 병합으로 간주될 수 있으며 트렁크 자체는 라인이다.

분산 버전 관리에서 여러 저장소가 존재하는 경우 이들은 단일 원본 버전(트리의 루트)을 기반으로 할 수 있지만, 반드시 원본 루트가 있을 필요는 없으며 각 저장소마다 별도의 루트(가장 오래된 리비전)가 있을 수 있다. 예를 들어 두 사람이 별도로 프로젝트를 시작하는 경우 이런 일이 발생할 수 있다. 마찬가지로, 데이터를 교환하거나 병합하는 여러 데이터 세트(여러 프로젝트)가 있는 경우, 비록 단순화를 위해 한 프로젝트를 기본으로, 다른 프로젝트를 부차적인 것으로 생각하여 자체 리비전 이력 유무와 관계없이 첫 번째 프로젝트에 병합할 수 있지만 단일 루트는 존재하지 않는다.

전문화된 전략

[편집]

공학 리비전 관리는 초기 청사진이나 백사진“MIL-STD-100G: Department of Defense Standard Practice for Engineering Drawings” (PDF). United States Department of Defense. 1997년 6월 9일. 2026년 5월 16일에 확인함. 의 리비전을 추적하는 공식화된 프로세스에서 발전했다. 이 제어 시스템은 설계 개발 과정에서 공학적 막다른 골목에 도달한 경우 설계를 이전 상태로 되돌리는 것을 암묵적으로 허용했다. 리비전 테이블은 변경 사항을 추적하는 데 사용되었다. 또한 도면의 수정된 영역은 리비전 클라우드를 사용하여 강조 표시되었다.

비즈니스 및 법률

[편집]

버전 관리는 비즈니스와 법률 분야에서 널리 퍼져 있다. 실제로 "계약 레드라인"과 "법률 블랙라인"은 가장 초기 형태의 리비전 관리 중 일부이며[10] 비즈니스와 법률 분야에서 다양한 수준의 정교함으로 여전히 사용되고 있다. 가장 정교한 기술은 전통적인 리비전 관리의 "수동" 전자적 구현을 대체하면서 CAD 파일의 변경 사항을 전자적으로 추적하는 데 사용되기 시작했다.[11]

게임 개발

[편집]

게임 개발은 종종 대규모 바이너리 파일과 다양한 분야에 걸쳐 함께 작업하는 팀을 포함한다. 결과적으로 게임 스튜디오는 대규모 바이너리 파일, 파일 잠금, 빠른 동기화를 잘 지원하는 버전 관리 시스템을 사용한다. 일반적인 도구로는 퍼포스(Perforce)와 여러 새로운 클라우드 기반 시스템이 있다.[12][13]

소스 관리 모델

[편집]

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

원자적 작업

[편집]

작업이 중단되더라도 시스템이 일관된 상태로 유지되면 그 작업은 원자적이다. 커밋 작업은 보통 이런 의미에서 가장 중요하다. 커밋은 리비전 관리 시스템에 변경 그룹을 최종화하고 모든 사용자에게 제공하도록 지시한다. 모든 버전 관리 시스템이 원자적 커밋을 지원하는 것은 아니며, CVS (버전 관리 시스템)에는 이 기능이 없다.[14]

파일 잠금

[편집]

"동시 접속" 문제를 방지하는 가장 간단한 방법은 파일을 잠가서 한 번에 한 명의 개발자만 해당 파일의 중앙 "저장소" 사본에 대한 쓰기 권한을 갖도록 하는 것이다. 한 개발자가 파일을 "체크아웃"하면 다른 사람들은 그 파일을 읽을 수는 있지만, 해당 개발자가 업데이트된 버전을 "체크인"(또는 체크아웃 취소)할 때까지 다른 사람은 그 파일을 변경할 수 없다.

파일 잠금에는 장점과 단점이 모두 있다. 사용자가 대용량 파일(또는 파일 그룹)의 많은 섹션을 급격하게 변경할 때 어려운 편집 충돌로부터 어느 정도 보호를 제공할 수 있다. 파일이 너무 오랫동안 독점적으로 잠겨 있으면 다른 개발자가 리비전 관리 소프트웨어를 우회하여 로컬에서 파일을 변경하려는 유혹을 느낄 수 있으며, 결국 다른 변경 사항이 체크인될 때 어려운 수동 병합을 강제하게 된다. 대규모 조직에서는 개발자가 프로젝트 사이를 이동함에 따라 파일이 "체크아웃"된 채 잠겨 방치될 수 있다. 이러한 도구는 누가 파일을 체크아웃했는지 쉽게 파악할 수 있게 할 수도 있고 그렇지 않을 수도 있다.

버전 병합

[편집]

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

두 파일을 병합하는 것은 매우 섬세한 작업일 수 있으며, 일반적으로 텍스트 파일처럼 데이터 구조가 단순한 경우에만 가능하다. 두 이미지 파일을 병합한 결과는 이미지 파일이 아닐 수도 있다. 파일을 체크인하는 두 번째 개발자는 병합 시 주의를 기울여 변경 사항이 호환되는지, 병합 작업이 파일 내에 자체 논리 오류를 도입하지 않는지 확인해야 한다. 이러한 문제는 자동 또는 반자동 병합 작업의 가용성을 주로 단순한 텍스트 기반 문서로 제한하며, 해당 파일 형식에 대한 특정 병합 플러그인을 사용할 수 있는 경우는 예외이다.

예약된 편집 개념은 병합 기능이 존재하는 경우에도 독점적인 쓰기 권한을 위해 파일을 명시적으로 잠그는 선택적인 수단을 제공할 수 있다.

베이스라인, 라벨 및 태그

[편집]

대부분의 리비전 관리 도구는 스냅샷을 식별("프로젝트 라벨 지정")하거나 스냅샷의 기록("베이스라인 X로 시도")을 지칭하는 행위를 언급하기 위해 베이스라인, 라벨, 태그와 같은 유사한 용어 중 하나만 사용한다. 일반적으로 베이스라인, 라벨, 태그 중 하나의 용어만 문서나 논의에서 사용되며[15] 이들은 동의어로 간주될 수 있다.

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

베이스라인이라는 용어와 라벨 또는 태그 중 하나가 같은 맥락에서 함께 사용될 때, 라벨과 태그는 일반적으로 스냅샷을 식별하거나 기록을 만드는 도구 내의 메커니즘을 지칭하며, 베이스라인은 주어진 라벨이나 태그의 중요도가 증가했음을 나타낸다.

구성 관리에 대한 대부분의 공식적인 논의에서는 베이스라인이라는 용어를 사용한다.

분산 버전 관리

[편집]

분산 버전 관리 시스템(DRCS)은 중앙 집중식 시스템의 클라이언트 서버 모델 접근 방식과 반대로 피어 투 피어 접근 방식을 취한다. 클라이언트가 동기화하는 단일 중앙 저장소 대신, 각 피어의 코드 베이스 작업 사본이 실제 저장소이다.[16] 분산 버전 관리는 피어 간에 패치(변경 세트)를 교환하여 동기화를 수행한다. 이는 중앙 집중식 시스템과 몇 가지 중요한 차이를 가져온다.

  • 기본적으로 코드 베이스의 표준 참조 사본은 존재하지 않으며, 작업 사본만 존재한다.
  • 중앙 서버와 통신할 필요가 없으므로 일반적인 작업(커밋, 이력 보기, 변경 사항 되돌리기 등)이 빠르다.[1]: 7 

오히려 다른 피어로부터 변경 사항을 푸시하거나 가져올 때만 통신이 필요하다.

  • 각 작업 사본은 코드 베이스와 변경 이력의 원격 백업으로 효과적으로 기능하여 데이터 손실에 대한 본질적인 보호를 제공한다.[1]: 4 

모범 사례

[편집]

버전 관리의 완전한 이점을 얻으려면 모범 사례를 따르는 것이 필요하다. 모범 사례는 버전 관리 도구 및 버전 관리가 적용되는 분야에 따라 다를 수 있다. 소프트웨어 개발에서 일반적으로 받아들여지는 모범 사례는 다음과 같다: 작고 점진적인 변경을 수행할 것, 하나의 작업이나 수정만 포함하는 커밋을 수행할 것—이에 대한 부수적인 원칙으로 작동하고 기존 기능을 의도적으로 깨뜨리지 않는 코드만 커밋할 것—, 릴리스 전에 기능을 완료하기 위해 브랜치를 사용할 것, 명확하고 설명적인 커밋 메시지를 작성하여 무엇을, 왜, 어떻게 했는지 커밋 설명이나 코드에 명확히 할 것, 일관된 브랜치 전략을 사용할 것.[17] 코드 검토 및 자동화된 회귀 테스트와 같은 다른 소프트웨어 개발 모범 사례는 버전 관리 모범 사례를 따르는 데 도움이 될 수 있다.

비용과 이점

[편집]

비용과 이점은 선택한 버전 관리 도구와 그것이 적용되는 분야에 따라 달라진다. 이 섹션은 버전 관리가 널리 적용되는 소프트웨어 개발 분야에 대해 다룬다.

비용

[편집]

버전 관리 소프트웨어 라이선스 비용 외에도 버전 관리를 사용하는 데에는 시간과 노력이 필요하다. 버전 관리의 기본 개념을 이해해야 하며 선택한 버전 관리 소프트웨어를 운영하는 데 필요한 기술적 세부 사항을 학습해야 한다. 버전 관리 모범 사례를 학습하고 조직의 기존 소프트웨어 개발 관행에 통합해야 한다. 유용한 이점을 얻기 위해 모범 사례를 따르는 데 필요한 규율을 유지하는 데 관리 노력이 필요할 수 있다.

이점

[편집]

변경 사항 되돌리기 허용

[편집]

핵심 이점은 이력을 유지하고 변경 사항을 되돌리는 기능으로, 개발자가 변경 사항을 쉽게 취소할 수 있도록 한다. 이는 개발자에게 실험할 더 많은 기회를 제공하여 기존 코드를 망칠 것이라는 두려움을 없애준다.[18]

브랜칭은 전개, 유지보수 및 개발을 단순화함

[편집]

브랜칭은 전개 및 릴리스 관리를 지원한다. 브랜칭 및 병합, 소스 코드 패치의 생성, 패키징 및 라벨링, 코드 베이스에 대한 패치의 쉬운 적용은 개발, 테스트, 스테이징, 운영 등 전개 프로세스의 다양한 단계와 관련된 여러 코드 베이스의 유지보수 및 동시 개발을 단순화한다.[19]

피해 완화, 책임성, 프로세스 및 설계 개선

[편집]

버전 관리가 제공하는 기록 유지, 누가 무엇을, 언제, 왜, 어떻게 했는지에 대한 추적과 관련된 피해 완화, 책임성, 프로세스 및 설계 개선 등의 이점이 있을 수 있다.[20]

버그가 발생하면 언제 무엇을 했는지 아는 것은 어떤 문제가 존재하는지, 얼마나 오래 존재했는지, 문제 범위와 해결책을 결정하는 데 도움이 되어 피해 완화 및 복구를 지원한다.[21] 이전 버전을 설치하고 테스트하여 코드와 커밋 메시지 조사에서 도출된 결론을 검증할 수 있다.[22]

디버깅 단순화

[편집]

버전 관리는 디버깅을 크게 단순화할 수 있다. 여러 버전에 테스트 케이스를 적용하면 버그를 도입한 변경 사항을 빠르게 식별할 수 있다.[23] 개발자는 전체 코드 베이스에 익숙할 필요가 없으며 문제를 도입한 코드에 집중할 수 있다.

협업 및 커뮤니케이션 향상

[편집]

버전 관리는 여러 면에서 협업을 강화한다. 버전 관리는 충돌하는 변경 사항, 즉 동일한 코드 라인에 대해 이루어진 호환되지 않는 변경 사항을 식별할 수 있으므로 개발자 간의 조정 필요성이 줄어든다.[24]

커밋, 브랜치 및 모든 관련 커밋 메시지와 버전 라벨의 패키징은 즉각적으로나 시간이 지남에 따라 개발자 간의 커뮤니케이션을 향상시킨다.[25] 즉각적이든 지연되든 더 나은 커뮤니케이션은 코드 검토 프로세스, 테스트 프로세스 및 소프트웨어 개발 프로세스의 기타 중요한 측면을 개선할 수 있다.

통합

[편집]

더 고급 리비전 관리 도구 중 일부는 다른 도구 및 소프트웨어 공학 프로세스와 더 깊은 통합을 허용하는 많은 다른 시설을 제공한다.

통합 개발 환경

[편집]

오라클 JDeveloper, IntelliJ IDEA, 이클립스, 비주얼 스튜디오, 델파이, 넷빈즈 IDE, 엑스코드, GNU 이맥스(vc.el을 통해)와 같은 통합 개발 환경을 위한 플러그인을 흔히 사용할 수 있다. 고급 연구 프로토타입은 적절한 커밋 메시지를 생성한다.[26]

공통 용어

[편집]

시스템마다 용어가 다를 수 있지만 일반적으로 사용되는 용어는 다음과 같다:[27]

베이스라인

[편집]

후속 변경을 가할 수 있는 문서 또는 소스 파일의 승인된 리비전. 베이스라인, 라벨 및 태그 참조.

Blame

[편집]

특정 라인을 마지막으로 수정한 작성자와 리비전을 찾는 검색.

브랜치

[편집]

버전 관리 하에 있는 파일 세트는 특정 시점에 브랜치되거나 포크되어 그 이후부터 두 파일 사본이 서로 독립적으로 다른 속도나 방식으로 개발될 수 있다.

변경

[편집]

변경(또는 Diff, 또는 델타)은 버전 관리 하의 문서에 대한 특정 수정을 나타낸다. 변경으로 간주되는 수정의 세분성은 버전 관리 시스템마다 다르다.

변경 리스트

[편집]

원자적 다중 변경 커밋이 있는 많은 버전 관리 시스템에서 변경 리스트(또는 CL), 변경 세트, 업데이트 또는 패치는 단일 커밋에서 수행된 변경 세트를 식별한다. 이는 또한 소스 코드를 순차적으로 볼 수 있게 하여 특정 변경 리스트 ID 시점의 소스를 조사할 수 있게 한다.

체크아웃

[편집]

체크아웃(또는 co)은 저장소에서 로컬 작업 사본을 만드는 것이다. 사용자는 특정 리비전을 지정하거나 최신 버전을 가져올 수 있다. '체크아웃'이라는 용어는 작업 사본을 설명하는 명사로도 사용될 수 있다. 공유 파일 서버에서 파일을 체크아웃하면 다른 사용자가 편집할 수 없다. 호텔과 같이 체크아웃하면 더 이상 편의 시설에 접근할 수 없다고 생각하면 된다.

클론

[편집]

클론은 다른 저장소의 리비전을 포함하는 저장소를 만드는 것을 의미한다. 이는 비어 있는(새로 초기화된) 저장소로 푸시하거나 풀하는 것과 같다. 명사로 두 저장소가 동기화된 상태로 유지되고 동일한 리비전을 포함하는 경우 클론이라고 할 수 있다.

커밋 (명사)

[편집]

커밋 (동사)

[편집]

커밋(체크인, ci 또는 더 드물게 설치, 제출 또는 기록)은 작업 사본에서 수행된 변경 사항을 저장소에 다시 쓰거나 병합하는 것이다. 커밋은 메타데이터, 일반적으로 작성자 정보와 변경 사항을 설명하는 커밋 메시지를 포함한다.

커밋 메시지

[편집]

개발자가 작성하여 커밋과 함께 저장되는 커밋을 설명하는 짧은 메모. 이상적으로는 수정이 왜 이루어졌는지, 수정의 효과나 목적에 대한 설명, 변경 사항이 작동하는 방식 중 명확하지 않은 측면을 기록한다.

충돌

[편집]

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

델타 압축

[편집]

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

동적 스트림

[편집]

일부 또는 모든 파일 버전이 상위 스트림 버전의 미러인 스트림.

내보내기

[편집]

내보내기는 저장소에서 파일을 가져오는 행위이다. 작업 사본에서 사용되는 버전 관리 메타데이터 없이 깨끗한 디렉터리 트리를 만든다는 점을 제외하면 체크아웃과 유사하다. 이는 예를 들어 콘텐츠를 게시하기 전에 자주 사용된다.

가져오기(Fetch)

[편집]

풀(pull) 참조.

순방향 통합

[편집]

메인 트렁크에서 수행된 변경 사항을 개발(기능 또는 팀) 브랜치로 병합하는 프로세스.

[편집]

팁이라고도 불리며 트렁크 또는 브랜치에 대한 가장 최근 커밋을 지칭한다. 트렁크와 각 브랜치는 고유한 헤드를 가지고 있지만, HEAD는 때때로 트렁크를 지칭하기 위해 느슨하게 사용되기도 한다.[28]

가져오기(Import)

[편집]

가져오기는 (현재 작업 사본이 아닌) 로컬 디렉터리 트리를 처음으로 저장소에 복사하는 행위이다.

초기화

[편집]

새로운 빈 저장소를 만드는 것.

인터리브 델타

[편집]

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

라벨

[편집]

태그 참조.

잠금

[편집]

개발자가 파일을 잠그면 잠금이 해제될 때까지 다른 누구도 해당 파일을 업데이트할 수 없다. 잠금은 버전 관리 시스템에 의해 지원되거나 개발자 간의 비공식적인 커뮤니케이션(일명 소셜 잠금)을 통해 지원될 수 있다.

메인라인

[편집]

트렁크와 유사하지만 각 브랜치에 대한 메인라인이 있을 수 있다.

병합

[편집]

병합 또는 통합은 두 개의 변경 세트가 파일 또는 파일 세트에 적용되는 작업이다. 몇 가지 샘플 시나리오는 다음과 같다:

  • 파일 세트를 작업 중인 사용자가 다른 사용자가 만든 변경 사항(저장소에 체크인됨)으로 작업 사본을 업데이트하거나 동기화한다.[29]
  • 사용자가 파일이 체크아웃된 이후 다른 사람들에 의해 업데이트된 파일을 체크인하려고 시도하고, 버전 관리 소프트웨어가 자동으로 파일을 병합한다(일반적으로 자동 병합을 진행할지 묻고, 경우에 따라 명확하고 합리적으로 해결할 수 있는 경우에만 수행함).
  • 브랜치가 생성되고 파일의 코드가 독립적으로 편집된 후, 업데이트된 브랜치가 나중에 단일 통합 트렁크에 포함된다.
  • 파일 세트가 브랜치되고 브랜칭 이전에 존재했던 문제가 한 브랜치에서 수정된 다음, 해당 수정 사항이 다른 브랜치로 병합된다. (이러한 유형의 선택적 병합은 이전 경우의 완전한 병합과 구별하기 위해 체리 픽이라고도 한다.)

승격(Promote)

[편집]

파일 콘텐츠를 덜 제어되는 위치에서 더 제어되는 위치로 복사하는 행위. 예를 들어 사용자의 작업 공간에서 저장소로, 또는 스트림에서 상위 스트림으로 복사하는 것이다.[30]

풀(Pull), 푸시(Push)

[편집]

한 저장소에서 다른 저장소로 리비전을 복사한다. 풀은 수신 저장소에 의해 시작되고 푸시는 소스에 의해 시작된다. 페치(Fetch)는 때때로 풀의 동의어로 사용되거나 풀 후 업데이트를 의미하기도 한다.

풀 리퀘스트

[편집]
이 문단은 다음의 발췌 내용입니다: 분산 버전 관리 § 풀 리퀘스트.[편집]

분산 버전 관리 시스템을 사용하는 소스 코드 저장소의 기여는 풀 리퀘스트(pull request), 즉 머지 리퀘스트(merge request)라는 방식을 통해 이루어지는 것이 보통이다.[31] 프로젝트 관리자가 소스코드 변경사항을 풀(pull)하는 기여자 요청이므로 "풀 리퀘스트"라는 이름이 붙게 되었다. 유지보수자는 기여가 소스 베이스의 일부가 되게 하기 위해 풀 리퀘스트를 병합해야 한다.[32]

개발자는 새 변경사항을 유지보수자에게 알리기 위해 풀 리퀘스트를 생성한다. 댓글 스레드가 개별 풀 리퀘스트에 연결된다. 이를 통해 코드 변경에 대한 집중화된 토론이 가능해진다. 제출된 풀 리퀘스트들은 저장소 접근이 가능한 누구나 볼 수 있다. 풀 리퀘스트는 유지보수자들에 의해 수락되거나 거절될 수 있다.[33]

풀 리퀘스트가 검토되고 승인되면 저장소에 병합된다. 확립된 워크플로에 따라 코드는 공식 릴리스에 포함되기 전에 테스트할 필요가 있을 수 있다. 그러므로 일부 프로젝트들은 테스트되지 않은 풀 리퀘스트를 병합하기 위한 특수한 브랜치가 포함되어 있다.[32][34] 그 밖의 프로젝트들은 모든 풀 리퀘스트에 대한 자동화된 테스트 스위트를 수행하며 이는 Travis CI 등의 CI 도구를 사용함으로써 이루어지며, 새로운 코드에 적절한 테스트 커버리지가 있는지를 리뷰어가 검사한다.

저장소

[편집]
이 문단은 다음의 발췌 내용입니다: 저장소 (버전 관리).[편집]

버전 관리 시스템에서 저장소 또는 리포지터리(repository)[35]는 파일이나 디렉터리 구조의 집합을 위해 메타데이터를 저장하는 자료 구조이다. 사용 중인 버전 관리 시스템이 분산 방식(예: Git 또는 머큐리얼)인지, 아니면 중앙 집중 방식(예: (서브버전 또는 퍼포스)인지에 따라 저장소 내 정보 전반이 모든 사용자 시스템에 복제되거나 단일 서버 상에서 관리될 수 있다. 저장소에 들어가는 메타데이터에는 다음과 같은 것들이 포함된다:

  • 저장소의 역사적 변경 기록.
  • 커밋 객체의 집합.
  • 헤드(head)라는 이름의 커밋 객체의 참조 집합.

해결(Resolve)

[편집]

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

역방향 통합

[편집]

버전 관리 시스템의 메인 트렁크로 서로 다른 팀 브랜치를 병합하는 프로세스.

리비전과 버전

[편집]

버전은 형태의 모든 변경 사항이다. SVK에서 리비전은 저장소 내 전체 트리의 특정 시점 상태이다.

공유

[편집]

하나의 파일이나 폴더를 여러 브랜치에서 동시에 사용할 수 있게 만드는 행위. 공유 파일이 한 브랜치에서 변경되면 다른 브랜치에서도 변경된다.

스트림

[편집]

다른 컨테이너와 알려진 관계를 가진 브랜치된 파일용 컨테이너. 스트림은 계층 구조를 형성하며 각 스트림은 상위 스트림으로부터 다양한 속성(리비전, 네임스페이스, 워크플로 규칙, 구독자 등)을 상속받을 수 있다.

태그

[편집]

태그 또는 라벨은 많은 파일에 걸쳐 일관된 중요한 스냅샷을 지칭한다. 해당 시점의 파일들은 모두 사용자 친화적이고 의미 있는 이름이나 리비전 번호로 태그될 수 있다. 베이스라인, 라벨 및 태그 참조.

트렁크

[편집]

트렁크는 브랜치가 아닌 고유한 개발 라인이다(때때로 베이스라인, 메인라인 또는 마스터라고도 불림[36][37])

업데이트

[편집]

업데이트(또는 동기화, 단 동기화는 푸시와 풀의 결합을 의미할 수도 있음)는 저장소에서 수행된 변경 사항(예: 다른 사람들에 의한 것)을 로컬 작업 사본으로 병합한다. 업데이트는 일부 CM 도구(CM+, PLS, SMS)에서 변경 패키지 개념(변경 리스트 참조)에 사용되는 용어이기도 하다. 각 저장소마다 정확히 하나의 작업 사본을 가져야 하는 리비전 관리 시스템(분산 시스템에서 흔함)에서는 체크아웃과 동의어로 사용된다.

잠금 해제

[편집]

잠금을 해제하는 것.

작업 사본

[편집]

작업 사본은 특정 시간이나 리비전에서 저장소에 있는 파일의 로컬 사본이다. 저장소의 파일에 대해 수행되는 모든 작업은 처음에 작업 사본에서 수행되므로 이러한 이름이 붙었다. 개념적으로는 샌드박스이다.

같이 보기

[편집]

각주

[편집]
  1. 1 2 3 4 O'Sullivan, Bryan (2009). 《Mercurial: the Definitive Guide》. Sebastopol: O'Reilly Media, Inc. ISBN 978-0-596-55547-4. 2019년 12월 8일에 원본 문서에서 보존된 문서. 2015년 9월 4일에 확인함.
  2. ↑ 〈Google Docs〉, 《See what's changed in a file》, Google Inc., 2022년 10월 6일에 원본 문서에서 보존된 문서, 2021년 4월 21일에 확인함.
  3. ↑ Scott, Chacon; Straub, Ben (2014). 《Pro Git Second Edition》 (영어). United States: Apress. 14쪽. 2015년 12월 25일에 원본 문서에서 보존된 문서. 2022년 2월 19일에 확인함.
  4. ↑ Goetz, Martin (2002년 5월 3일). 《An Interview with Martin Goetz》. 인터뷰어: Jeffrey R. Yost. Washington, D.C.: Charles Babbage Institute, University of Minnesota. 5–7쪽. 2024년 9월 26일에 원본 문서에서 보존된 문서. 2023년 8월 17일에 확인함.
  5. ↑ Piscipo, Joseph (2002년 5월 3일). 《An Interview with Joseph Piscopo》. 인터뷰어: Thomas Haigh. Washington, D.C.: Charles Babbage Institute, University of Minnesota. 3, 5, 12–13쪽. 2024년 9월 26일에 원본 문서에서 보존된 문서. 2023년 8월 17일에 확인함.
  6. ↑ Rochkind, Marc J. (1975). “The Source Code Control System” (PDF). 《IEEE Transactions on Software Engineering》 SE–1 (4): 364–370. Bibcode:1975ITSEn...1..364R. doi:10.1109/TSE.1975.6312866. S2CID 10006076. 2020년 9월 30일에 원본 문서 (PDF)에서 보존된 문서. 2020년 9월 3일에 확인함.
  7. ↑ Tichy, Walter F. (1985). “Rcs — a system for version control”. 《Software: Practice and Experience》 15 (7): 637–654. doi:10.1002/spe.4380150703. ISSN 0038-0644. S2CID 2605086. 2024년 9월 26일에 원본 문서에서 보존된 문서. 2023년 12월 28일에 확인함.
  8. ↑ Collins-Sussman, Ben; Fitzpatrick, BW; Pilato, CM (2004), 《Version Control with Subversion》, O'Reilly, ISBN 0-596-00448-6
  9. ↑ Loeliger, Jon; McCullough, Matthew (2012). 《Version Control with Git: Powerful Tools and Techniques for Collaborative Software Development》. O'Reilly Media. 2–5쪽. ISBN 978-1-4493-4504-4. 2024년 9월 26일에 원본 문서에서 보존된 문서. 2023년 3월 22일에 확인함.
  10. ↑ 공학 도면의 경우, 백사진#문서 제어를 참조할 것. 20세기에 사용된 수동 시스템 중 일부, 예를 들어 로렌스 A. 하일랜드의 승인이 필요한 휴즈 항공의 공학 절차 등; 또한 미국 정부가 제정한 승인 절차 참조.
  11. ↑ Kim, Jin-Hyun; Han, Sung-Lim; Lee, Kwang-Hyeon (2013). “A Web-Based Revision Control Framework for 3D CAD Model Data”. 《International Journal of Precision Engineering and Manufacturing》 14 (9): 1575–1582. doi:10.1007/s12541-013-0214-4.
  12. ↑ Zitzman, Sharone (2023년 5월 9일). “5 Version-Control Tools Game Developers Should Know About” (미국 영어). 《The New Stack》. 2025년 11월 29일에 확인함.
  13. ↑ “Collaboration and Version Control in Unreal Engine | Unreal Engine 5.7 Documentation | Epic Developer Community” (미국 영어). 《Epic Games Developer》. 2025년 11월 29일에 확인함.
  14. ↑ Smart, John Ferguson (2008). 《Java Power Tools》 (영어). O'Reilly Media, Inc. 301쪽. ISBN 978-1-4919-5454-6. 2024년 9월 26일에 원본 문서에서 보존된 문서. 2019년 7월 20일에 확인함.
  15. ↑ Sink, Eric (2011). 《Version Control by Example》 (PDF). Pyrenean Gold Press.
  16. ↑ Wheeler, David. “Comments on Open Source Software / Free Software (OSS/FS) Software Configuration Management (SCM) Systems”. 2020년 11월 9일에 원본 문서에서 보존된 문서. 2007년 5월 8일에 확인함.
  17. ↑ GitLab. “What are Git version control best practices?”. 《gitlab.com》. 2022년 11월 11일에 확인함.
  18. ↑ Alessandro Picarelli (2020년 11월 17일). “The cost of not using version control”. 2022년 11월 19일에 원본 문서에서 보존된 문서. 2022년 11월 18일에 확인함. In terms of man hours it’s going to cost you 6 to 48 times what it would have cost you using version control, and that’s for rewinding a couple of models for a single developer.
  19. ↑ Irma Azarian (2023년 6월 14일). “A Review of Software Version Control: Systems, Benefits, and Why it Matters”. 2024년 9월 26일에 원본 문서에서 보존된 문서. 2022년 11월 18일에 확인함. Version control systems allow you to compare files, identify differences, and merge the changes if needed prior to committing any code. Versioning is also a great way to keep track of application builds by being able to identify which version is currently in development, QA, and production.
  20. ↑ ReQtest (2020년 10월 26일). “What Are The Benefits Of Version Control?”. 2022년 11월 22일에 원본 문서에서 보존된 문서. 2022년 11월 21일에 확인함. The history of the document provides invaluable information about the author and the date of editing. It also gives on the purpose of the changes made. It will have an impact on the developer that works on the latest version as it will help to solve problems experienced in earlier versions. The ability to identify the author of the document enables the current team to link the documents to specific contributors. This, in turn, enables the current team to uncover patterns that can help with fixing bugs. This will help to improve the overall functionality of the software.
  21. ↑ Chiradeep BasuMallick (2022년 10월 6일). “What Is Version Control? Meaning, Tools, and Advantages”. 2022년 11월 19일에 원본 문서에서 보존된 문서. 2022년 11월 18일에 확인함. Software teams can understand the evolution of a solution by examining prior versions through code reviews.
  22. ↑ Chiradeep BasuMallick (2022년 10월 6일). “What Is Version Control? Meaning, Tools, and Advantages”. 2022년 11월 19일에 원본 문서에서 보존된 문서. 2022년 11월 18일에 확인함. If an error is made, developers can go back in time and review prior iterations of the code to remedy the mistake while minimizing disturbance for all team members.
  23. ↑ Chacon, Scott; Straub, Ben (2022년 10월 3일). “Pro Git” Version 2.1.395-2-g27002dd판. Apress. 2024년 9월 26일에 원본 문서에서 보존된 문서. 2022년 11월 18일에 확인함. The git bisect tool is an incredibly helpful debugging tool used to find which specific commit was the first one to introduce a bug or problem by doing an automatic binary search.
  24. ↑ Irma Azarian (2023년 6월 14일). “A Review of Software Version Control: Systems, Benefits, and Why it Matters”. 2024년 9월 26일에 원본 문서에서 보존된 문서. 2022년 11월 18일에 확인함. Versioning is a priceless process, especially when you have multiple developers working on a single application, because it allows them to easily share files. Without version control, developers will eventually step on each other’s toes and overwrite code changes that someone else may have completed without even realizing it. Using these systems allows you to check files out for modifications, then, during check-in, if the files have been changed by another user, you will be alerted and allowed to merge them.
  25. ↑ Jesse Phillips (2019년 1월 21일). “Git is a Communication tool”. 2022년 11월 19일에 원본 문서에서 보존된 문서. 2022년 11월 18일에 확인함. There are continued discussions on using rebase, merge, and/or squash. I want to bring focus to the point of all these choices, communicating.
  26. ↑ Cortes-Coy, Luis Fernando; Linares-Vasquez, Mario; Aponte, Jairo; Poshyvanyk, Denys (2014). 〈On Automatically Generating Commit Messages via Summarization of Source Code Changes〉. 《2014 IEEE 14th International Working Conference on Source Code Analysis and Manipulation》. IEEE. 275–284쪽. doi:10.1109/scam.2014.14. ISBN 978-1-4799-6148-1. S2CID 360545.
  27. ↑ Wingerd, Laura (2005). 《Practical Perforce》. O'Reilly. ISBN 0-596-10185-6. 2007년 12월 21일에 원본 문서에서 보존된 문서. 2006년 8월 27일에 확인함.
  28. ↑ Gregory, Gary (2011년 2월 3일). “Trunk vs. HEAD in Version Control Systems”. 《Java, Eclipse, and other tech tidbits》. 2020년 9월 20일에 원본 문서에서 보존된 문서. 2012년 12월 16일에 확인함.
  29. ↑ Collins-Sussman, Fitzpatrick & Pilato 2004, 1.5: SVN tour cycle resolve: ‘The G stands for merGed, which means that the file had local changes to begin with, but the changes coming from the repository didn't overlap with the local changes.’
  30. ↑ 《Concepts Manual》 Version 4.7판. Accurev. July 2008.
  31. ↑ Sijbrandij, Sytse (2014년 9월 29일). “GitLab Flow”. 《GitLab》. 2019년 9월 26일에 원본 문서에서 보존된 문서. 2018년 8월 4일에 확인함.
  32. 1 2 Johnson, Mark (2013년 11월 8일). “What is a pull request?”. 《Oaawatch》. 2016년 3월 27일에 확인함.
  33. ↑ “Using pull requests”. GitHub. 2019년 1월 28일에 원본 문서에서 보존된 문서. 2016년 3월 27일에 확인함.
  34. ↑ “Making a Pull Request”. Atlassian. 2020년 2월 6일에 원본 문서에서 보존된 문서. 2016년 3월 27일에 확인함.
  35. ↑ “SVNBook”. 2012년 4월 20일에 확인함.
  36. ↑ Wallen, Jack (2020년 9월 22일). “GitHub to replace master with main starting in October: What developers need to do now”. 《TechRepublic》. 2021년 2월 8일에 원본 문서에서 보존된 문서. 2022년 4월 24일에 확인함.
  37. ↑ Heinze, Carolyn (2020년 11월 24일). “Why GitHub renamed its master branch to main”. 《TheServerSide》. 2022년 5월 26일에 원본 문서에서 보존된 문서. 2022년 4월 24일에 확인함.
내용주
  1. ↑ 이 경우 편집 버퍼는 작업 사본의 2차 형태이며, 그렇게 불리지 않는다.
  2. ↑ 원칙적으로 두 리비전이 동일한 타임스탬프를 가질 수 있으므로 선상에서 순서를 정할 수 없다. 이는 일반적으로 별도의 저장소의 경우이며, 단일 저장소 내의 여러 브랜치에 대한 동시 변경도 가능하다. 이러한 경우 리비전은 저장소 또는 브랜치당 하나의 개별 라인 세트로 생각할 수 있다.
  3. ↑ 리비전 또는 저장소 "트리"를 작업 사본의 디렉터리 트리와 혼동해서는 안 된다.
  4. ↑ 새 브랜치가 HEAD에 기반을 두면 위상적으로 HEAD는 자식이 있으므로 더 이상 팁이 아니다.
  5. ↑ "메인라인"은 별도의 브랜치의 메인 경로를 지칭할 수도 있다.
원본 주소 "https://ko.wikipedia.org/w/index.php?title=버전_관리&oldid=42116785"