ISO/IEC/IEEE 24765 용어집은 버전 관리(version control)를 베이스라인을 세우고 유지하며, 베이스라인의 변경을 식별하고 통제해 앞 베이스라인으로 돌아갈 수 있게 하는 일로 정의한다.[1] SWEBOK V4.0a에 따르면 버전 관리는 소스 코드, 형상 파일, 관련 산출물을 저장하며, 형상 관리를 돕는 도구의 하나다.[2]

용어

ISO/IEC/IEEE 24765 용어집은 버전 관리의 용어를 다음처럼 정의한다.[1]

  • 브랜치(branch): 형상 항목의 주 개발 줄기에서 갈라져 나와, 여러 사람이 같은 항목을 동시에 작업할 수 있게 하는 것. 진화하는 소스 파일 버전의 묶음으로도 정의한다.
  • trunk: 소프트웨어의 주 개발 줄기로, 대부분 브랜치의 출발점
  • 병합(merge): 같은 파일에 가한 서로 다른 변경을 합치는 것
  • 커밋(commit): 개발자의 개인 뷰에서 소스 코드에 가한 변경을, 버전 관리 시스템의 저장소를 거쳐 접근할 수 있는 브랜치에 통합하는 것
  • 태그(tag): 특정 릴리스나 브랜치에 붙인 기호 이름
  • 저장소(repository): 시스템에 속한 소프트웨어 관련 산출물 전체의 모음, 또는 그 모음을 저장하는 위치·형식[1]

도구가 하는 일

SWEBOK V4.0a에 따르면 소스 코드 버전 관리 도구는 엔지니어 팀이나 엔지니어 한 사람이 소스 코드의 변경을 추적하고 문서로 남기게 한다. 이 도구는 소스 코드를 저장하는 단일 저장소를 두어 여러 엔지니어가 같은 모듈을 동시에 고치지 못하게 할 수 있고, 소스 코드에 가한 모든 변경을 기록한다. 엔지니어는 저장소에서 모듈을 체크아웃해 고치고, 변경을 문서로 남긴 뒤 고친 모듈을 저장소에 다시 넣는다. 필요하면 변경을 버리고 앞 베이스라인으로 되돌릴 수도 있다. 더 강력한 도구는 병렬 개발과 지리적으로 분산된 환경을 지원한다. 소스 코드를 버전 관리 시스템에 두면 개발한 베이스라인의 추적성과 보안을 얻고, 버전 관리 시스템은 여러 개발 흐름을 지원한다.[2]

브랜치·병합 전략

SWEBOK V4.0a는 브랜치·병합 전략이 많은 소프트웨어 형상 관리 활동에 영향을 주므로 신중히 계획하고 알리기를 권한다. 병합은 대개 둘 이상의 사람이 한 형상 항목을 바꿀 때 일어나고, 널리 쓰이는 브랜치·병합 전략은 여러 가지다. 형상 관리 계획을 실행하려면 대개 하위 절차를 따로 두어 어떤 브랜치 전략을 쓸지 정하고, 도구를 고를 때 따질 물음에는 도구의 기능이 계획한 브랜치·병합 전략과 맞는지가 든다.[2]

도구의 갈래

버전 관리 도구는 소스 코드와 외부 문서 같은 개별 형상 항목을 추적하고 문서로 남기고 저장하며, 빌드 처리 도구, 변경 통제 도구와 함께 개별 지원 도구에 든다. 개별 지원 도구는 소프트웨어 제품의 변형을 내지 않고 복잡한 형상 관리 요구도 없는 작은 조직이나 개발 그룹에 대개 충분하다. 프로젝트 관련 지원 도구는 주로 개발 팀과 통합 담당자의 작업 공간 관리를 지원하고 분산 개발 환경도 지원할 수 있으며, 제품 변형과 병렬 개발을 쓰되 인증 요구가 없는 중대형 조직에 알맞다. 전사 프로세스 지원 도구는 워크플로, 역할과 책임 같은 전사 프로세스의 일부를 자동화하고, 인증 요구를 포함한 더 공식적인 개발 프로세스를 지원한다.[2]

병렬 수정 통제

ASPICE 4.1은 SUP.8의 BP(base practice) 가운데 BP3으로, 식별한 형상 항목을 통제하는 형상 관리 메커니즘을 세우고 여기에 형상 항목의 병렬 수정을 통제하는 메커니즘을 포함하게 한다. BP3의 주석은 형상 항목 종류마다 따로 둘 수 있는 메커니즘의 예로 브랜치·병합 관리와 체크아웃 통제를 든다.[3]

Git

Git에서 브랜치는 개발의 한 줄기이고, 브랜치의 가장 최근 커밋을 그 브랜치의 tip이라 한다. 저장소 하나는 브랜치를 얼마든지 추적할 수 있지만, 작업 트리는 그 가운데 체크아웃된 브랜치 하나에만 연결된다. 커밋은 명사로는 이력의 한 지점이고, 프로젝트의 전체 이력은 서로 이어진 커밋의 집합으로 나타난다. 다른 버전 관리 시스템이 revision이나 version이라 부르는 자리에 Git은 흔히 커밋이라는 말을 쓴다. 동사로서 커밋은 인덱스의 현재 상태를 나타내는 새 커밋을 만들어 프로젝트 상태의 스냅숏을 이력에 저장하는 일이다. 태그는 refs/tags/ 이름공간 아래의 ref로, 대개 커밋 조상 사슬의 한 지점을 표시하는 데 쓰며, head와 달리 commit 명령으로 바뀌지 않는다.[4]

[1]
IEEE Computer Society, “SEVOCAB: Software and Systems Engineering Vocabulary (ISO/IEC/IEEE 24765).” 2026. Accessed: Oct. 02, 2026. [Online]. Available: https://pascal.computer.org/sev_display/index.action
[2]
H. Washizaki, Ed., “Guide to the Software Engineering Body of Knowledge (SWEBOK Guide), Version 4.0a,” IEEE Computer Society, 2026. Accessed: Oct. 02, 2026. [Online]. Available: https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf
[3]
“Automotive SPICE Process Reference Model / Process Assessment Model, Version 4.1,” VDA Quality Management Center, 2026. Accessed: Oct. 02, 2026. [Online]. Available: https://vda-qmc.de/wp-content/uploads/2026/09/Automotive-SPICE-PAM-v41.pdf
[4]
Git project, “gitglossary - A Git Glossary.” 2026. Accessed: Oct. 12, 2026. [Online]. Available: https://git-scm.com/docs/gitglossary