버전 관리

3. 기본 개념 및 용어

버전 관리 시스템은 파일의 변경 이력을 체계적으로 관리하기 위한 도구이며, 여러 기본적인 개념과 용어를 포함한다.
저장소 (Repository)는 파일의 현재 버전과 모든 변경 이력 정보를 저장하는 핵심적인 저장 공간이다. 저장소는 서버(Server)에 위치할 수도 있고, 로컬에 존재할 수도 있다. 사용자는 저장소에서 파일을 체크 아웃 (Check Out)하여 자신의 작업 환경인 작업 copy (Working Copy)로 가져온다.

파일을 처음 저장소에 복사하는 과정을 가져오기 (Import)라고 한다. 이는 버전 관리 시스템의 통제 하에 파일을 두는 첫걸음이다.

작업 copy에서 파일을 수정한 후에는 체크 인 (Check In) 또는 커밋 (Commit) 과정을 거쳐 변경 사항을 저장소에 반영한다. 이때, 체크 인 메시지를 통해 변경 사항에 대한 설명을 추가하여 추후 이력 추적을 용이하게 한다. 저장소에 예치된 파일은 개정판 (Revision)으로 관리되며, 각 개정판은 고유한 식별자를 가진다.
수정 기록 (Change log / History)은 파일의 모든 변경 이력을 기록하며, 누가 언제 어떤 변경을 했는지 확인할 수 있게 해준다.

여러 사람이 동시에 작업하는 환경에서는 동기화 (Update / Sync) 과정을 통해 자신의 작업 copy를 최신 상태로 유지해야 한다. 동기화는 저장소의 최신 변경 사항을 자신의 작업 copy에 반영하는 것을 의미한다.

작업을 하다 보면 여러 갈래의 개발 흐름이 필요할 수 있다. 이때 가지치기 (Branch)를 통해 독립적인 개발 라인을 생성할 수 있다. 이후, 분리된 브랜치에서의 변경 사항을 합치기 (Merge)를 통해 주류 (Trunk / Main) 또는 다른 브랜치에 통합할 수 있다.

만약 동일한 파일을 여러 사람이 동시에 수정했을 경우 충돌 (Conflict)이 발생할 수 있다. 이때는 차이 보기 (Diff) 도구를 사용하여 변경 사항을 비교하고, 해소 (Resolve) 과정을 통해 충돌을 해결해야 한다. 특정 파일에 대한 동시 접근을 막기 위해 잠금 (Locking) 기능을 사용할 수도 있다.

예를 들어, 갑돌이가 파일을 저장소에 추가 (Add)한 후, 해당 파일을 인출 (Check out)한다. 갑돌이는 인출한 파일을 수정한 다음, 저장소에 예치 (Check in / Commit)하면서 수정에 대한 설명을 덧붙인다. 다음 날, 을순이가 자신의 작업 공간을 동기화 (Update / Sync)한다. 이때 갑돌이가 추가했던 파일이 을순이의 작업 copy에 반영된다. 을순이는 해당 파일의 수정 기록 (Change log / History)을 확인하여 갑돌이가 처음 추가한 파일과 이후 변경된 파일의 차이 (Diff)를 비교할 수 있다.

3. 1. 핵심 용어

3. 2. 작업 흐름

4. 구조

## 구조

버전 관리 시스템은 시간에 따른 데이터 변경 사항을 관리하며, 이러한 변경 사항은 다양한 방식으로 구성될 수 있다. 데이터는 종종 파일이나 문서와 같은 개별 항목의 모음으로 취급되며, 각 파일에 대한 변경 사항이 추적된다. 그러나 Git과 같은 시스템은 데이터 변경 사항을 전체적으로 고려하여 파일 이름 변경, 분할 또는 병합과 같은 복잡한 변경 사항을 단순화한다.

수정 관리 하에 있는 데이터는 '체크아웃'을 통해 검색된 후 수정되며, 수정 관리 시스템('저장소')에 즉시 반영되지 않고 '체크인' 또는 '커밋' 과정을 거친다. 수정 관리 외부에 있는 복사본은 "작업 복사본"이라고 한다. 예를 들어, 컴퓨터 파일을 편집할 때 편집 프로그램에 의해 메모리에 저장된 데이터는 작업 복사본이며 저장을 통해 커밋된다. 소스 코드 관리의 경우, 작업 복사본은 특정 수정본의 모든 파일 복사본이며 일반적으로 개발자 컴퓨터에 로컬로 저장된다.^[10] 파일을 저장해도 작업 복사본만 변경되며, 저장소에 체크인하는 것은 별도의 단계이다.

여러 사람이 단일 데이터 세트 또는 문서에서 작업하는 경우, 작업 복사본에서 데이터 분기가 생성되므로 병합 문제가 발생할 수 있다. 간단한 공동 문서 편집에서는 파일 잠금을 사용하거나 다른 사람이 작업하는 동일한 문서에서 작업을 피함으로써 이를 방지할 수 있다.

수정 관리 시스템은 중앙 집중식 구조를 가질 수 있으며, 이 경우 단일 권한 데이터 저장소인 '저장소'를 통해 체크아웃 및 체크인이 수행된다. 반면, 분산 수정 관리 시스템에서는 단일 저장소가 권한을 가지지 않으며, 데이터를 모든 저장소에서 체크아웃하고 체크인할 수 있다. 다른 저장소에 체크인할 때는 병합 또는 패치로 처리된다.

분산 버전 관리 시스템에서는 각 로컬 저장소가 전체 프로젝트의 완전한 사본을 가지고 있어 독립적으로 버전 관리를 수행할 수 있다. 중앙 집중식 시스템과는 달리 단일 장애점이 존재하지 않으며, 개발자는 네트워크 연결 없이도 변경 사항을 커밋하고 브랜치를 생성할 수 있어, 네트워크 연결이 불안정한 환경에서 유용하다. 이러한 분산 구조는 향상된 안정성, 오프라인 작업, 유연성, 속도 향상 등의 장점을 제공하지만, 설정 및 관리의 복잡성, 학습 곡선, 저장 공간 요구량 증가 등의 단점도 존재한다.

그래프 이론 관점에서 개정은 일반적으로 '트렁크'라고 불리는 개발 라인에서 분기되어 나오며, 이는 유향 트리를 형성하여 하나 이상의 병렬 개발 라인("브랜치 메인라인")으로 시각화된다. 실제 구조는 더 복잡하여 유향 비순환 그래프를 형성하지만, 많은 경우 "병합이 있는 트리"는 적절한 근사치로 간주된다.

개정은 시간 순서대로 발생하며, 개정 번호 또는 타임스탬프를 기준으로 정렬할 수 있다.^[11] 개정은 이전 개정을 기반으로 하며, 이전 개정을 거의 또는 완전히 대체하는 것도 가능하다. 분기 또는 실행 취소가 없으면 각 개정은 바로 이전 개정만을 기반으로 하며, 단일 최신 버전인 "HEAD" 개정 또는 ''팁''과 함께 단순한 라인을 형성한다. 그래프 이론 용어로, 각 개정을 점으로 그리고 각 "파생된 개정" 관계를 화살표로 그리면 이는 선형 그래프가 된다. 분기가 있어 여러 개의 미래 개정이 이전 개정을 기반으로 하거나, 실행 취소가 있어 개정이 바로 이전 개정보다 오래된 개정에 의존할 수 있는 경우, 결과 그래프는 대신 유향 트리가 되며, 자식이 없는 개정("각 브랜치의 최신 개정")에 해당하는 여러 팁이 있다.^[12] 원칙적으로 결과 트리는 선호되는 팁("주요" 최신 개정)을 가질 필요가 없으며, 단지 다양한 개정이 있을 뿐이지만, 실제로 하나의 팁은 일반적으로 HEAD로 식별된다. 새 개정이 HEAD를 기반으로 할 때, 새 HEAD로 식별되거나 새 분기로 간주된다.^[13] 시작부터 HEAD까지의 개정 목록(그래프 이론 용어로, 트리 내의 고유한 경로)은 ''트렁크'' 또는 ''메인라인''이다.^[14]

반대로, 개정이 둘 이상의 이전 개정을 기반으로 할 수 있을 때, 결과 프로세스를 ''병합''이라고 하며 개정 관리의 가장 복잡한 측면 중 하나이다. 이는 여러 분기에서 변경이 발생한 다음 두 변경 사항을 모두 통합하여 단일 분기로 병합될 때 가장 자주 발생한다. 이러한 변경 사항이 겹치면 병합하기 어려울 수 있거나 불가능할 수 있으며, 수동 개입 또는 다시 쓰기가 필요할 수 있다.

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

분산 개정 관리에서는 여러 저장소가 있는 경우 단일 원본 버전(트리의 루트)을 기반으로 할 수 있지만, 원본 루트가 있을 필요는 없으며, 대신 각 저장소에 대해 별도의 루트(가장 오래된 개정)가 있을 수 있다. 이는 예를 들어, 두 사람이 별도로 프로젝트 작업을 시작하는 경우 발생할 수 있다. 마찬가지로, 데이터를 교환하거나 병합하는 여러 데이터 세트(여러 프로젝트)가 있는 경우, 단일 루트는 없지만 단순화를 위해 한 프로젝트를 기본으로, 다른 프로젝트를 보조로 생각하고 자체 개정 기록을 포함하거나 포함하지 않고 첫 번째 프로젝트로 병합할 수 있다.

4. 1. 중앙 집중식 구조

4. 2. 분산 구조

• 향상된 안정성: 중앙 서버의 장애가 전체 시스템에 영향을 미치지 않는다. 각 저장소가 독립적으로 작동하므로, 하나의 저장소가 손상되더라도 다른 저장소를 통해 복구할 수 있다.
• 오프라인 작업: 네트워크 연결 없이도 로컬에서 커밋, 브랜치 생성, 변경 사항 검토 등의 작업을 수행할 수 있다.
• 유연성: 모든 저장소가 동등한 권한을 가지므로, 개발자는 자유롭게 데이터를 체크아웃하고 체크인할 수 있다.
• 속도: 로컬 저장소에서 대부분의 작업을 처리하므로, 중앙 서버와의 통신으로 인한 지연 시간을 줄일 수 있다.

• 복잡성: 중앙 집중식 시스템에 비해 설정 및 관리가 더 복잡할 수 있다.
• 학습 곡선: 분산 버전 관리 시스템의 개념과 사용법을 익히는 데 시간이 걸릴 수 있다.
• 저장 공간: 각 저장소가 전체 프로젝트의 사본을 가지므로, 더 많은 저장 공간이 필요하다.

4. 3. 그래프 구조

5. 소스 관리 모델

소스 관리 모델에는 여러 개발자가 동시에 작업할 때 발생할 수 있는 문제점을 해결하기 위한 다양한 방법이 존재한다. 전통적인 버전 관리 시스템은 중앙 집중식 모델을 사용하며, 모든 버전 관리 기능은 공유 서버에서 이루어진다. 만약 두 명의 개발자가 동시에 동일한 파일을 변경하려 할 때 접근 권한 관리 방법이 없다면 서로의 작업 내용을 덮어쓰는 상황이 발생할 수 있다. 중앙 집중식 버전 관리 시스템은 파일 잠금과 버전 병합이라는 두 가지 방법을 통해 이러한 문제를 해결한다.
버전 병합대부분의 버전 관리 시스템은 여러 개발자가 동시에 동일한 파일을 편집하는 것을 허용한다. 이때 중앙 저장소에 변경 사항을 먼저 "체크인"하는 개발자가 우선적으로 성공한다. 이후 시스템은 추가 변경 사항을 중앙 저장소에 병합하고, 다른 개발자가 체크인할 때 첫 번째 개발자의 변경 사항을 보존하는 기능을 제공한다.

두 파일을 병합하는 작업은 매우 복잡하며, 일반적으로 텍스트 파일과 같이 단순한 데이터 구조를 가진 경우에만 가능하다. 예를 들어, 두 이미지 파일을 병합한 결과는 이미지 파일이 아닐 수도 있다. 따라서 코드를 체크인하는 두 번째 개발자는 변경 사항이 호환되는지, 병합 작업이 파일 내에 논리적 오류를 발생시키지 않는지 주의해야 한다. 이러한 이유로 자동 또는 반자동 병합 작업은 특정 병합 플러그인이 해당 파일 형식에 사용 가능한 경우가 아니면 주로 텍스트 기반 문서에만 적용된다. 병합 기능이 존재하더라도, 필요에 따라 파일을 명시적으로 잠가 독점적인 쓰기 권한을 확보하는 '예약된 편집' 기능을 제공하는 시스템도 있다.
원자적 연산연산이 중단되더라도 시스템이 일관된 상태를 유지하면 해당 연산을 ''원자적''이라고 한다. 특히 ''커밋'' 연산은 변경 사항 그룹을 최종적으로 확정하고 모든 사용자가 사용할 수 있도록 리비전 관리 시스템에 지시하는 중요한 작업이다. 모든 리비전 관리 시스템이 원자적 커밋을 지원하는 것은 아니며, 동시 버전 시스템은 이 기능을 제공하지 않는다.^[16]

5. 1. 파일 잠금 (File Locking)

5. 2. 버전 병합 (Version Merging)

5. 3. 원자적 연산

6. 특화된 전략

엔지니어링 청사진의 개정 이력을 추적하는 공식화된 프로세스에서 엔지니어링 버전 관리가 발전했다. 이 시스템은 개발이 막다른 길에 다다랐을 때 이전 설계 상태로 되돌릴 수 있도록 허용하며, 변경 사항 추적을 위해 개정 테이블을 사용하고 도면 수정 영역은 개정 구름으로 강조 표시한다.

6. 1. 비즈니스 및 법률

6. 2. 엔지니어링 버전 관리

7. 분산 버전 관리

분산 버전 관리 시스템(DRCS)은 클라이언트-서버 방식을 사용하는 중앙 집중식 시스템과 달리 피어 투 피어 방식을 채택한다. 각 피어는 코드베이스의 작업 복사본을 가지며, 이는 완전한 저장소 역할을 한다.^[17]

동기화는 피어 간 패치(변경 세트) 교환을 통해 이루어진다. 다른 피어에서 변경 사항을 푸시하거나 풀할 때만 통신이 필요하며, 이는 중앙 집중식 시스템과 중요한 차이점이다.

분산 버전 관리의 주요 장점은 작업 속도와 데이터 손실 방지 기능이다. 커밋, 기록 보기, 변경 사항 되돌리기 등의 작업은 중앙 서버와의 통신 없이 로컬에서 처리되므로 빠르다.^[1] 각 작업 복사본은 코드베이스와 변경 기록의 원격 백업 역할을 수행하여 데이터 손실에 대한 보호 기능을 제공한다.^[1] 코드베이스의 정식 참조 복사본은 존재하지 않고 작업 복사본만이 존재한다.

7. 1. 피어 투 피어 방식

7. 2. 동기화

7. 3. 장점

8. 모범 사례

버전 관리 시스템을 효과적으로 활용하기 위해서는 몇 가지 모범 사례를 따르는 것이 중요하다. 이러한 사례는 사용하는 도구나 적용 분야에 따라 달라질 수 있지만, 일반적으로 소프트웨어 개발에서 널리 받아들여지는 방법들이 존재한다.

점진적이고 작은 단위로 변경을 수행하고, 하나의 작업 또는 수정 사항만을 포함하는 커밋을 하는 것이 중요하다.^[18] 이는 커밋하는 코드가 항상 작동 가능해야 하며, 기존 기능을 의도적으로 손상시키지 않도록 하기 위함이다. 릴리스 전에는 분기를 사용하여 기능을 완성하고, 명확하고 설명적인 커밋 메시지를 작성하여 커밋 내용과 이유, 방법을 명확히 설명해야 한다.^[18] 또한, 일관된 분기 전략을 사용하는 것이 좋다.^[18]

코드 검토는 여러 개발자가 코드를 검토하여 결함을 찾고 코드 품질을 개선하는 데 도움을 준다. 자동화된 회귀 테스트는 코드 변경으로 인해 기존 기능이 손상되지 않았는지 확인하는 데 유용하다. 코드 검토는 개발자들이 서로의 코드를 검토하면서 잠재적인 문제점을 발견하고, 코드의 품질을 향상시키는 데 기여한다. 회귀 테스트는 코드 변경 후 기존 기능이 제대로 작동하는지 자동으로 검증하는 과정으로, 안정적인 소프트웨어 개발에 필수적이다.

버전 관리 시스템의 일반적인 사용 흐름은 다음과 같다. 먼저, 개발자(예: 갑돌이)가 파일을 저장소에 추가한다. 그 후, 해당 파일을 인출하여 수정한 다음, 변경 사항에 대한 설명을 덧붙여 저장소에 다시 예치한다. 다른 개발자(예: 을순이)는 자신의 작업 공간을 동기화하여 갑돌이가 추가하고 수정한 파일을 전달받는다. 을순이는 파일의 수정 기록을 보면서 갑돌이가 처음 추가한 파일과 이후 변경된 파일의 차이를 확인할 수 있다. 이러한 과정을 통해 협업이 원활하게 이루어지고, 코드 변경 사항을 추적하고 관리할 수 있다.

8. 1. 소프트웨어 개발

• 점진적이고 작은 변경을 수행한다.
• 하나의 작업 또는 수정 사항만 포함하는 커밋을 수행한다. 결과적으로 작동하고 기존 기능을 의도적으로 손상시키지 않는 코드만 커밋해야 한다.
• 릴리스 전에 분기를 사용하여 기능을 완료한다.
• 명확하고 설명적인 커밋 메시지를 작성하여 커밋 설명 또는 코드에서 무엇을, 왜, 어떻게 명확하게 표시한다.
• 일관된 분기 전략을 사용한다.^[18]

8. 2. 코드 검토 및 테스트

9. 비용 및 편익

## 비용 및 편익

버전 관리 시스템 도입 및 운영에 따른 비용과 편익은 선택된 도구와 적용 분야에 따라 다르지만, 소프트웨어 개발 분야에서 널리 활용되고 있다. 버전 관리 시스템은 조직의 핵심 자산인 소스 코드의 개정 및 백업 절차를 자동화하여 오류 수정 과정을 돕고, 국제 협력 개방 소프트웨어 개발 실무에서도 널리 사용된다.
편익버전 관리 시스템을 사용하는 주요 이유는 다음과 같다.

• 오류 발생 시 복구 지원
• 과거 특정 시점으로의 복귀 가능
• 팀 협업 시 수정 사항 동기화 자동화
• 소스 코드 변경 이력 및 수정 주체 추적
• 대규모 수정 작업의 안정성 확보
• 가지치기(Branch)를 통한 독립적인 개발
• 접붙이기(Merge)를 통한 검증된 기능 통합
• 오픈 소스 프로젝트에서의 활용
• 코드의 의미 추적

9. 1. 비용

9. 2. 편익

• 잘못되었을 때 복구를 돕기 위해
• 프로젝트 진행 중 과거의 시점으로 돌아갈 수 있게 하기 위해
• 여러 사람이 같은 프로젝트에 참여할 경우, 각자가 수정한 부분을 팀원 전체가 동기화하는 과정을 자동화하기 위해
• 소스 코드의 변경 사항을 추적하기 위해
• 소스 코드에서 누가 수정했는지 추적하기 위해
• 대규모 수정 작업을 안전하게 진행하기 위해
• 가지내기(Branch)로 프로젝트에 영향을 최소화하면서 새로운 부분을 개발하기 위해
• 접붙이기(Merge)로 검증이 끝난 후 새로이 개발된 부분을 본류(trunk)에 합치기 위해
• 많은 오픈 소스 프로젝트에서 어떠한 형태로든 버전 관리를 사용하고 있으므로
• 코드의 특정 부분이 왜 그렇게 쓰여 졌는지 의미를 추적하기 위해

9. 2. 1. 변경 사항 되돌리기

• 오류 발생 시 복구 지원
• 과거 특정 시점으로의 복귀 가능
• 팀 협업 시 수정 사항 동기화 자동화
• 소스 코드 변경 이력 추적
• 수정 주체 추적
• 대규모 수정 작업의 안정성 확보
• 가지치기(Branch)를 통한 독립적인 개발
• 접붙이기(Merge)를 통한 검증된 기능 통합
• 오픈 소스 프로젝트에서의 활용
• 코드의 의미 추적

9. 2. 2. 배포, 유지보수, 개발 간소화

9. 2. 3. 피해 완화, 책임 규명, 프로세스 개선

• 무언가 잘못되었을 때 복구를 돕기 위함
• 프로젝트 진행 중 과거의 어떤 시점으로 돌아갈 수 있게 하기 위함
• 여러 사람이 같은 프로젝트에 참여할 경우, 각자가 수정한 부분을 팀원 전체가 동기화하는 과정을 자동화하기 위함
• 소스 코드의 변경 사항을 추적하기 위함
• 소스 코드에서 누가 수정했는지 추적하기 위함
• 대규모 수정 작업을 더욱 안전하게 진행하기 위함
• 가지내기(Branch)로 프로젝트에 영향을 최소화하면서 새로운 부분을 개발하기 위함
• 접붙이기(Merge)로 검증이 끝난 후 새로이 개발된 부분을 본류(trunk)에 합치기 위함
• 많은 오픈 소스 프로젝트에서 어떠한 형태로든 버전 관리를 사용하고 있으므로
• 코드의 특정 부분이 왜 그렇게 쓰여 졌는지 의미를 추적하기 위함

9. 2. 4. 디버깅 간소화

9. 2. 5. 협업 및 의사소통 개선

• 문제가 발생했을 때 복구를 지원하기 위해
• 프로젝트 진행 중 특정 시점으로 되돌아가기 위해
• 여러 사람이 동일한 프로젝트에 참여할 때 각자의 수정 사항을 동기화하기 위해
• 소스 코드 변경 사항 및 수정자를 추적하기 위해
• 대규모 수정 작업을 안전하게 진행하기 위해
• 가지치기(Branch)를 통해 프로젝트 영향 최소화 및 새로운 기능 개발을 위해
• 접붙이기(Merge)를 통해 검증된 기능을 본류(trunk)에 통합하기 위해
• 코드의 특정 부분이 왜 그렇게 작성되었는지 추적하기 위해

10. 통합

버전 관리 도구는 다른 도구 및 소프트웨어 엔지니어링 프로세스와 통합되어 다양한 기능을 제공한다. 예를 들어, 이슈 추적 시스템과 연동하여 특정 버전에 대한 변경 사항을 추적하거나, 지속적 통합(CI) 도구와 연동하여 코드 변경 시 자동으로 빌드 및 테스트를 수행할 수 있다. 이러한 통합은 개발 효율성을 높이고 소프트웨어 품질을 향상시키는 데 기여한다.

10. 1. 통합 개발 환경 (IDE)

11. 일반적인 용어

버전 관리 시스템에서 일반적으로 사용되는 용어는 시스템마다 차이가 있을 수 있지만, 다음은 널리 사용되는 용어들에 대한 설명이다.^[28]

• Blame: 특정 줄을 마지막으로 수정한 작성자와 해당 개정 버전을 찾는 기능이다.

• Branch (브랜치): 특정 시점에서 파일 세트가 브랜치되거나 포크될 수 있다. 이는 해당 시점부터 파일의 복사본들이 서로 독립적으로 개발될 수 있음을 의미한다.

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

• Change list (변경 목록): '''변경 목록'''(change list, CL), '''변경 집합'''(change set), '''업데이트'''(update) 또는 '''패치'''는 단일 커밋에서 이루어진 변경의 집합을 식별한다. 이는 원자적 트랜잭션 기반의 다중 변경 커밋을 지원하는 버전 관리 시스템에서 사용되며, 소스 코드의 순차적 보기를 나타낼 수 있다. 특정 변경 목록 ID 시점의 소스를 검사할 수 있게 해준다.

• Checkout (체크아웃): ''체크아웃''(check out, co)은 저장소에서 로컬 작업 복사본을 생성하는 것을 의미한다. 사용자는 특정 개정판을 지정하거나 최신 버전을 가져올 수 있다. '체크아웃'이라는 용어는 작업 복사본을 설명하는 명사로도 사용될 수 있다. 파일을 공유 파일 서버에서 체크아웃한 경우 다른 사용자는 해당 파일을 편집할 수 없다.

• Clone (클론): 클로닝은 다른 저장소의 개정판을 포함하는 저장소를 만드는 것을 의미한다. 이것은 비어 있는 저장소로 푸시하거나 풀하는 것과 동일하다. 두 저장소가 동기화되어 있고 동일한 개정판을 포함하고 있다면 두 저장소를 서로의 클론이라고 할 수 있다.

• Commit (커밋): 커밋(Commit)은 작업 복사본에서 이루어진 변경 사항을 저장소에 다시 쓰거나 병합하는 것을 의미한다. 이를 변경 집합이라고도 한다. 커밋 시에는 변경 사항에 대한 설명인 커밋 메시지를 함께 기록한다.

• Commit message (커밋 메시지): 커밋은 작업 사본에서 변경된 사항을 저장소에 반영하는 과정이다. 커밋 시에는 변경 사항에 대한 설명인 커밋 메시지를 함께 기록한다. 커밋 메시지는 왜 변경이 이루어졌는지, 어떤 효과가 있는지, 변경의 목적은 무엇인지 등을 간략하게 설명하는 메모 역할을 한다. 커밋 메시지에는 일반적으로 작성자 정보와 같은 메타데이터가 포함된다.

• Conflict (충돌): 여러 개발자가 같은 파일의 동일한 부분을 동시에 수정했을 때 발생한다. 시스템이 자동으로 변경 사항을 병합할 수 없을 때 발생하며, 수동으로 해결해야 한다. 충돌을 효과적으로 해결하려면 변경 사항을 이해하고, 다른 개발자와 협력하며, 충돌 해결 후 테스트를 수행해야 한다. 잦은 업데이트, 명확한 커밋 메시지, 기능별 브랜치, 커뮤니케이션 등의 전략을 통해 충돌을 최소화할 수 있다.

• Delta compression (델타 압축): 파일의 연속적인 버전 간의 차이점만 보존하는 압축 방식이다. 이는 버전 관리 시스템에서 저장 공간을 효율적으로 사용하기 위해 널리 활용된다. Git과 같은 분산 버전 관리 시스템에서 효율적인 저장 및 전송을 위해 핵심적으로 사용되는 기술이다.

• Dynamic stream (동적 스트림): 대부분의 개정 관리 소프트웨어는 파일의 연속적인 버전 간의 차이점만 보존하는 델타 압축을 사용한다. 이를 통해 다양한 버전의 파일을 보다 효율적으로 저장할 수 있다.

• Export (내보내기): 저장소에서 파일을 가져오는 행위를 말한다. 이는 작업 복사본의 메타데이터 없이 깨끗한 디렉토리 트리를 생성하는 방식으로 이루어진다. 특정 시점의 파일들을 추출하여 다른 환경에서 사용하거나, 백업 목적으로 활용될 수 있다.

• Fetch (가져오기): 저장소에서 파일을 가져오는 행위이다. 이는 ''체크아웃''과 유사하지만, 작업 복사본에서 사용되는 버전 관리 메타데이터 없이 깨끗한 디렉터리 트리를 생성한다는 점에서 차이가 있다. 내용을 게시하기 전에 자주 사용된다.

• Forward integration (정방향 통합): 메인 트렁크에서 개발 브랜치로 변경 사항을 병합하는 과정을 의미하며, pull을 참고한다.

• Head (헤드): 현재 체크아웃된 커밋을 가리키는 포인터이다. 일반적으로 트렁크(trunk) 또는 브랜치를 가리키며, 현재 작업 중인 최신 커밋을 나타낸다.

• Import (가져오기): 로컬 디렉터리 트리를 저장소로 처음 복사하는 것을 의미한다. 최신 커밋을 가리키는 용어는 '헤드(HEAD)'이며, 때로는 '팁(tip)'이라고도 불린다. 트렁크 또는 브랜치에 적용되며, 트렁크와 각 브랜치는 자체적인 헤드를 가진다.

• Initialize (초기화): 새로운 빈 저장소를 만드는 것을 초기화라고 한다. 로컬 디렉토리 트리를 저장소로 처음 복사하는 것은 '''가져오기'''라고 한다.

• Interleaved deltas (교차 델타): 일부 버전 관리 소프트웨어는 교차 델타를 사용하는데, 이는 델타 압축을 사용하는 것보다 텍스트 기반 파일의 기록을 더 효율적으로 저장할 수 있는 방법이다.

• Label (레이블): 태그를 참고하라.

• Locking (잠금): 개발자가 파일을 잠금하면 다른 사람은 해당 파일이 잠금 해제될 때까지 업데이트할 수 없다. 잠금은 버전 관리 시스템에서 지원하거나 개발자 간의 비공식적인 의사소통을 통해 지원될 수 있다.

• Mainline (메인라인): 트렁크와 유사하지만, 각 브랜치마다 메인라인이 존재할 수 있다.

• Merge (병합): 두 세트의 변경 사항을 파일 또는 파일 세트에 적용하는 작업이다. 사용자가 파일 세트로 작업하면서 다른 사용자가 저장소에 변경하고 체크인한 내용을 사용하여 작업 사본을 업데이트하거나 동기화하는 등의 시나리오가 있다.

• Promote (승격): pull, push를 참고한다.

• Pull (풀), Push (푸시): 한 저장소에서 다른 저장소로 변경 사항을 복사하는 행위를 의미한다. 일반적으로 덜 통제된 위치에서 더 통제된 위치로 파일 내용을 복사하는 것을 지칭하며, 사용자의 작업 공간에서 중앙 저장소로 변경 사항을 반영하는 경우에 사용된다.

• Pull request (풀 리퀘스트): 분산 버전 관리 시스템에서 코드 변경 사항을 통합하기 위해 요청하는 것을 의미한다.

• Repository (저장소): 파일의 현재 버전과 변경 이력 정보를 저장하는 저장소를 의미한다.

• Resolve (해결): 동일 문서에 대한 서로 다른 변경 사항 간의 충돌을 해결하는 과정을 의미한다.

• Reverse integration (역방향 통합): 주 트렁크에 서로 다른 팀의 브랜치를 병합하는 과정이다.

• Revision (개정) and Version (버전): 버전은 형태의 모든 변화를 의미하며, 개정은 저장소 내 전체 트리의 특정 시점 상태를 의미한다.

• Share (공유): 여러 브랜치에서 동시에 특정 파일이나 폴더를 사용하는 것을 말한다.

• Stream (스트림): 분기된 파일들을 담는 컨테이너 역할을 하며, 다른 컨테이너들과의 관계를 나타낸다.

• Tag (태그): 스냅샷을 식별하는 행위("프로젝트에 레이블을 지정") 또는 스냅샷 기록("베이스라인 ''X''로 시도")을 지칭하기 위해 베이스라인, 레이블, 태그와 유사한 용어 중 하나를 사용한다.

• Trunk (트렁크): 브랜치가 아닌 고유한 개발 라인을 의미하며, 기준선, 메인라인 또는 마스터라고도 한다.

• Update (업데이트): 저장소에서 이루어진 변경 사항을 로컬 작업 사본에 병합하는 것을 업데이트라고 하며, 동기화라고도 한다.

• Unlocking (잠금 해제): 파일 잠금을 해제하는 행위를 의미한다.

• Working copy (작업 사본): 특정 시점 또는 리비전의 저장소에서 가져온 파일의 로컬 사본을 의미한다. 사용자는 이 사본을 통해 파일을 편집하고 변경 사항을 적용할 수 있다.

11. 1. Baseline (기준선)

11. 2. Blame

11. 3. Branch (브랜치)

11. 4. Change (변경)

11. 5. Change list (변경 목록)

11. 6. Checkout (체크아웃)

11. 7. Clone (클론)

11. 8. Commit (커밋)

11. 9. Commit message (커밋 메시지)

11. 10. Conflict (충돌)

• 동시 수정: 두 명 이상의 개발자가 같은 파일의 동일한 라인을 수정하고 변경 사항을 커밋했을 때.
• 병합 문제: 한 개발자가 변경 사항을 커밋하고 다른 개발자가 동일한 파일에 대한 이전 버전을 기반으로 변경 작업을 수행한 후 병합을 시도할 때.

• 변경 사항 이해: 충돌이 발생한 각 변경 사항의 의도를 정확히 파악한다.
• 협업: 다른 개발자와 협력하여 최적의 해결 방안을 모색한다.
• 테스트: 충돌 해결 후에는 변경 사항이 예상대로 작동하는지 확인하기 위해 테스트를 수행한다.

• 잦은 업데이트: 로컬 복사본을 자주 업데이트하여 최신 변경 사항을 반영한다.
• 명확한 커밋 메시지: 커밋 메시지를 통해 변경 사항의 내용과 목적을 명확하게 설명한다.
• 기능별 브랜치: 큰 변경 사항을 적용할 때는 별도의 브랜치를 사용하여 다른 개발자의 작업과 격리한다.
• 커뮤니케이션: 변경 사항에 대해 다른 개발자와 사전에 소통하여 잠재적인 충돌을 방지한다.

11. 11. Delta compression (델타 압축)

• 저장 공간 절약: 전체 파일을 저장하는 대신 변경 사항만 저장하므로 디스크 공간을 효율적으로 사용한다.
• 대역폭 감소: 네트워크를 통해 전송되는 데이터 양을 줄여 전송 시간을 단축하고 대역폭 사용량을 줄인다.
• 빠른 업데이트: 변경 사항만 전송하므로 업데이트 속도를 향상시킨다.

11. 12. Dynamic stream (동적 스트림)

11. 13. Export (내보내기)

11. 14. Fetch (가져오기)

11. 15. Forward integration (정방향 통합)

11. 16. Head (헤드)

11. 17. Import (가져오기)

11. 18. Initialize (초기화)

11. 19. Interleaved deltas (교차 델타)

11. 20. Label (레이블)

11. 21. Locking (잠금)

11. 22. Mainline (메인라인)

11. 23. Merge (병합)

11. 24. Promote (승격)

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

11. 25. Pull, push (풀, 푸시)

11. 26. Pull request (풀 리퀘스트)

11. 27. Repository (저장소)

11. 28. Resolve (해결)

11. 29. Reverse integration (역방향 통합)

11. 30. Revision and version (개정 및 버전)

11. 31. Share (공유)

11. 32. Stream (스트림)

11. 33. Tag (태그)

11. 34. Trunk (트렁크)

11. 35. Update (업데이트)

11. 36. Unlocking (잠금 해제)

11. 37. Working copy (작업 사본)

참조

_[1] 서적 Mercurial: the Definitive Guide http://hgbook.red-be[...] O'Reilly Media, Inc. 2015-09-04
_[2] 간행물 See what's changed in a file https://support.goog[...] Google Inc. 2021-04-21
_[3] 서적 Pro Git Second Edition https://git-scm.com/[...] Apress 2022-02-19
_[4] 인터뷰 An Interview with Martin Goetz https://conservancy.[...] Charles Babbage Institute, University of Minnesota 2023-08-17
_[5] 인터뷰 An Interview with Joseph Piscopo https://conservancy.[...] Charles Babbage Institute, University of Minnesota 2023-08-17
_[6] 학술지 The Source Code Control System https://basepath.com[...]
_[7] 학술지 Rcs — a system for version control https://docs.lib.pur[...] 2023-12-28
_[8] 간행물 Version Control with Subversion https://archive.org/[...] O'Reilly
_[9] 서적 Version Control with Git: Powerful Tools and Techniques for Collaborative Software Development https://books.google[...] O'Reilly Media 2023-03-22
_[10] 문서
_[11] 문서
_[12] 문서
_[13] 문서
_[14] 문서
_[15] 문서
_[16] 서적 Java Power Tools https://books.google[...] "O'Reilly Media, Inc." 2019-07-20
_[17] 웹사이트 Comments on Open Source Software / Free Software (OSS/FS) Software Configuration Management (SCM) Systems http://www.dwheeler.[...] 2007-05-08
_[18] 웹사이트 What are Git version control best practices? https://about.gitlab[...] 2022-11-11
_[19] 웹사이트 The cost of not using version control https://www.claytex.[...] 2022-11-18
_[20] 웹사이트 A Review of Software Version Control: Systems, Benefits, and Why it Matters https://www.seguetec[...] 2022-11-18
_[21] 웹사이트 What Are The Benefits Of Version Control? https://reqtest.com/[...] 2022-11-21
_[22] 웹사이트 What Is Version Control? Meaning, Tools, and Advantages https://www.spicewor[...] 2022-11-18
_[23] 웹사이트 What Is Version Control? Meaning, Tools, and Advantages https://www.spicewor[...] 2022-11-18
_[24] 웹사이트 Pro Git https://git-scm.com/[...] Apress 2022-11-18
_[25] 웹사이트 A Review of Software Version Control: Systems, Benefits, and Why it Matters https://www.seguetec[...] 2022-11-18
_[26] 웹사이트 Git is a Communication tool https://dev.to/jesse[...] 2022-11-18
_[27] 서적 2014 IEEE 14th International Working Conference on Source Code Analysis and Manipulation IEEE 2014
_[28] 서적 Practical Perforce http://safari.oreill[...] O'Reilly 2006-08-27
_[29] 웹사이트 Trunk vs. HEAD in Version Control Systems http://garygregory.w[...] 2012-12-16
_[30] 서적 Concepts Manual Accurev 2008-07
_[31] 웹사이트 GitHub to replace master with main starting in October: What developers need to do now https://www.techrepu[...] 2022-04-24
_[32] 웹사이트 Why GitHub renamed its master branch to main https://www.theserve[...] 2022-04-24
_[33] 서적 Mercurial: the Definitive Guide http://hgbook.red-be[...] O'Reilly Media, Inc. 2015-09-04