무엇에 대해 이야기할 것인가?
SVN(Subversion, 이하 SVN), 깃(Git, 이하 Git)과 같은 버전 관리 시스템(Version Control System)은 거의 모든 소프트웨어 개발 프로젝트에서 필수적인 요소로 인식되기에 개발자라면 반드시 알고 있어야 한다.
내가 참여한 모든 프로젝트에서는 기본적으로 SVN을 사용했다. 그러나 서점의 IT 전문서적이나 기업의 채용 공고 글에서는 대부분 Git에 대해 이야기했다. 이에 SVN과 Git의 어떠한 차이로 인해 내가 참여한 프로젝트에서는 SVN을 사용했고, 그들은 왜 Git을 다루는지 궁금해졌다.
이 글에서는 당연하게 사용했기 때문에 명확히 알지 못했던 개념에 대해 분명히 하고자 한다. 버전 관리란 무엇이고, 왜 사용해야 하는지 그리고 SVN과 Git에는 어떠한 차이가 있는지 알아보도록 하자.
버전 관리(Version Control)란?
버전 관리(Version Control, Revision Control), 소스 관리(Source Control), 소스 코드 관리(Source Code Management, SCM)란 동일한 정보에 대한 여러 버전을 관리하는 것을 말한다. 공학과 소프트웨어 개발에서 팀 단위로 개발 중인 소스 코드나, 청사진 같은 설계도 등의 디지털 문서를 관리하는데 사용된다.
소프트웨어 엔지니어링에서는 일반적으로 소프트웨어 소스 코드만을 관리하는 내역을 주로 버전 관리라고 정의하게 된다.
즉, SVN과 Git은 동일한 소스 코드를 여러 버전으로 관리하기 위한 시스템이다.
형상 관리(Configuration Management)란?
버전 관리와 함께 자주 사용되는 용어가 있다.
소프트웨어 구성 관리(Software Configuration Management, SCM) 또는 형상 관리는 소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 것으로, 형상 관리는 일반적으로 단순 버전관리 기반의 소프트웨어 운용을 좀 더 포괄적으로 학술 분야의 형태로 넓히는 근간을 이야기한다.
(형상 관리 = 버전 관리 + 소스 관리 + 개발 환경 관리 + 문서 관리 + 빌드 구조 관리 + ...)
버전 관리와 형상 관리는 흔히 동의어와 같이 사용되고, 사용할 수 있지만
그 정의를 분명히 한다면 형상 관리가 버전 관리를 포함한다고 볼 수 있다.
버전 관리를 이용해야 하는 이유
버전 관리 이용의 이유는 간단하게 말하자면 추후 발생할지도 모를 오류 수정에 대비하여 소스 코드를 백업하여 버전별로 안전하게 관리하고 협업하기 위함이다.
다음은 버전 관리 시스템을 사용하는 원인을 정리한 것이다.
- 무언가 잘못되었을 때 복구를 돕기 위하여
- 프로젝트 진행 중 과거의 어떤 시점으로 돌아갈 수 있게 하기 위하여
- 여러사람이 같은 프로젝트에 참여할 경우, 각자가 수정한 부분을 팀원 전체가 동기화하는 과정을 자동화하기 위하여
- 소스 코드의 변경 사항을 추적하기 위하여
- 소스 코드에서 누가 수정했는지 추적하기 위하여
- 대규모 수정 작업을 더욱 안전하게 진행하기 위하여
- 가지내기(Branch)로 프로젝트에 영향을 최소화 하면서 새로운 부분을 개발하기 위하여
- 접붙이기(Merge)로 검증이 끝난 후 새로이 개발된 부분을 본류(trunk)에 합치기 위하여
- 많은 오픈 소스 프로젝트에서 어떠한 형태로든 버전 관리를 사용하고 있으므로
- 코드의 특정 부분이 왜 그렇게 쓰여 졌는지 의미를 추적하기 위하여
버전 관리 용어
| 용어 | 설명 | 비고 |
|---|---|---|
| 저장소(Repository) | 파일의 현재 버전과 변경 이력 정보를 저장하는 저장소 | |
| 지역 저장소 (Local Repository) | 개별 컴퓨터에서 파일의 버전을 관리하는 저장소 | |
| 원격 저장소 (Remote Repository) | 온라인 상에서 파일의 버전을 관리하는 중앙 저장소 | |
| 작업 사본 (Working Copy) | 원본 저장소로부터 체크 아웃을 통해 내려 받은 로컬 컴퓨터에 있는 작업 사본 디렉토리 | ≒ Workspace |
| 작업 트리 (Working Tree) | 파일 수정, 저장 등의 작업을 하는 디렉터리 | ≒ 작업 디렉터리 Working Directory |
| 체크 아웃(Check Out) | 저장소(Repository)에서 파일을 가져오는 일 | |
| 체크인(Check In) | 체크 아웃한 파일의 수정이 끝난 후, 저장소에 새로운 버전으로 갱신하는 일 | |
| 가져오기(Import) | (버전 관리되고 있지 않은) 로컬 디렉토리의 파일을 처음으로 저장소에 복사하는 일 | |
| 내보내기(Export) | 체크 아웃과 달리 버전 관리 파일들을 제외한 순수한 소스 파일을 내보내는 일 (소스를 압축하여 릴리즈할 때 사용) | |
| 개정판(Revision) | 저장소에 저장된 파일의 버전 저장소에 새로운 파일이 커밋될 경우, 해당 파일의 Revision이 증가한다 | |
| 최신(Head) | 저장소에 추가된 최신 버전 파일 | |
| 추가(Add) | 새로운 파일을 추가하는 일 | |
| 갱신(Commit) | 체크 아웃한 소스 파일을 수정, 삭제, 파일을 추가한 뒤 저장소에 저장하여 갱신하는 일 | |
| 수정 기록(History) | 저장소 내 파일의 추가, 수정, 삭제 등의 변경 이력 | |
| 주류/본류(Trunk/Main) | 프로젝트에서 가장 중심이 되는 디렉토리 | |
| 가지내기(Branch) | Trunk 디렉토리에서 뻗어져 나온 가지로서 작은 단위의 프로젝트를 위한 디렉토리 | |
| 차이보기(Diff) | 동일한 소스 코드의 서로 다른 버전간 차이보기 | |
| 합치기(Merge) | 서로 다른 버전의 동일한 소스 코드 합치기 | |
| 충돌(Conflict) | 서로 다른 개발자가 동일한 소스 코드의 동일한 라인을 수정하고자 할 때 발생하는 현상 | |
| 동기화 (Update, Sync) | 저장소에 있는 최신 버전의 파일 또는 디렉토리를 가져옴 | |
| 스테이지(Stage) | 버전으로 만들 파일이 대기하는 곳 (커밋 전 단계) | ≒ 스테이징 영역 Staging Area |
버전 관리 종류
1. 로컬 버전 관리 시스템(Local Version Control System)
- 대표 시스템 : RCS(Revision Control System)
- 특징
RCS는 파일간 차이인 패치 세트를 특별한 형식으로 유지하고, 그것을 추가함으로써 모든 파일을 특정 시점으로 재생성할 수 있다.
2. 중앙집중식 버전 관리 시스템(Centralized Version Control System)
- 대표 시스템 : SVN(Subversion), CVS(Concurrent Version System), Perforce 등
- 특징
버전 관리되는 모든 파일을 저장하는 하나의 서버가 있고, 다수의 클라이언트가 중앙 서버에서 파일을 받아서 사용한다.(예, SVN에서의 체크아웃(Check Out)에 해당한다.) 중앙 서버 하나만을 사용하기 때문에 관리에 용이하다. 그러나 중앙 서버가 다운될 경우 협업이 불가능하고, 하드디스크의 중앙 데이터베이스에 문제가 발생할 경우 히스토리를 포함한 모든 정보가 소실될 위험이 있다.
3. 분산 버전 관리 시스템(Distributed Version Control System)
- 대표 시스템 : Git, Mecurial, Bazaar, Darcs 등
- 특징
클라이언트는 단순히 최신 파일의 마지막 스냅샷을 체크아웃(Check Out)하지 않고, 저장소와 히스토리를 모두 복제한다.(예, Git에서의 클론(Clone)에 해당한다.) 중앙집중식 버전 관리 시스템(CVCS)의 단점을 보완하여 중앙 서버에 문제가 발생해도 복구가 가능하며, 원격 저장소가 존재하여 다양한 그룹과 협업이 가능하다.
주요 버전 관리 도구
CVS(Concurrent Version System)이란?
CVS(Concurrent Version System, 동시 버전 시스템)는 소프트웨어 프로젝트를 진행할 때, 파일로 이뤄진 모든 작업과 모든 변화를 추적하고, 여러 개발자(지역적으로 떨어진)가 협력하여 작업할 수 있게 한다. CVS는 오픈 소스 프로젝트에서 널리 사용되었다가 현재는 한계를 맞아 대체하는 SVN이 개발되었다.
SVN(Subversion)이란?
서브버전(Subversion)은 자유 소프트웨어 버전 관리 시스템이다. 명령 줄 인터페이스에서 사용하는 명령어를 따라 SVN이라고 줄여서 부르기도 한다. 제한이 있던 CVS를 대체하기 위해 2000년부터 콜랩넷에서 개발되었다. 현재는 아파치 최상위 프로젝트로서 전 세계 개발자 커뮤니티와 함께 개발되고 있다.
Git이란?
깃(Git)은 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템이다. 소프트웨어 개발에서 소스 코드 관리에 주로 사용되지만 어떠한 파일 집합의 변경사항을 지속적으로 추적하기 위해 사용될 수 있다.
깃은 2005년 리눅스 커널 개발을 위해 초기 개발에 기여한 다른 커널 개발자들과 함께 2005년에 리누스 토르발스가 처음 개발한 것이다.
Git? GitHub? | GitHub란?
깃허브(GitHub)는 분산 버전 관리 툴인 깃 저장소 호스팅을 지원하는 웹 서비스이다. 즉, 분산 버전 관리, 소스 코드 공유, 이슈 트래킹 등이 가능한 원격 저장소라고 생각할 수 있다.
깃허브(GitHub) 외에도 깃 저장소 호스팅을 지원하는 웹 서비스는 깃랩(GitLab), 비트버킷(BitBucket) 등이 있다.
Git vs SVN
위 정의에도 나와 있듯이 Git은 분산 버전 관리 시스템(Distributed Version Control System)이고, SVN은 중앙집중식 버전 관리 시스템(Centralized Version Control System)이다. 버전 관리 방식에 의해 아래의 차이가 발생한다.
| 구분 | SVN | Git |
|---|---|---|
| 버전 관리 방식 | 중앙집중식 버전 관리 시스템(Centralized Version Control System) | 분산 버전 관리 시스템(Distributed Version Control System) |
| 저장소 | 로컬/원격 저장소 구분 없음(관리 용이/위험 부담), 중앙 저장소 즉시 반영 중앙 저장소 사용/인터넷 사용/느린 속도 | 로컬/원격 저장소 구분, 독립적 관리 가능 로컬 저장소(복사) 사용/인터넷 사용 불필요/빠른 속도 |
| 히스토리 | 버전 기록(version history) 없음 (버전 관리가 불가능한 일시적인 로컬 변경 기록(local history) 사용) | 커밋 기록(commit history) 있음 |
| 배포 방식 | 중앙 저장소 배포 | Branch별 병렬 개발 후, Master Branch 병합(Merge) 후 배포 |
Git vs SVN commands
Git과 SVN의 버전 관리 방식이 다르기 때문에 위 정리된 버전 관리 용어에 대해 사용자에 따라 다르게 이해할 수 있다.
예를 들어,
- SVN의 revert는 변경을 취소하지만 Git은 커밋을 되돌린다.
- SVN에서는 Branch와 Tag가 동일하지만 Git은 다르다.
- SVN은 로컬/원격 저장소라는 개념이 없기 때문에 커밋 즉시 원격 저장소에 반영되지만,
Git은 로컬 저장소 반영(Commit) 후, 원격 저장소에 반영(Push)한다.
SVN과 Git의 버전 관리 방식 차이로 발생하는 용어의 차이를 이해하고 커맨드를 비교해보자.
| Command | Operation | Subversion |
|---|---|---|
| git clone | 저장소 복사 | svn checkout |
| git commit | 파일 변경 사항 기록 | svn commit |
| git show | 커밋 상세 정보 확인 | svn cat |
| git status | 상태 확인 | svn status |
| git diff | 차이 확인 | svn diff |
| git log | 로그 확인 | svn log |
| git add | 추가 | svn add |
| git mv | 이동 | svn mv |
| git rm | 삭제 | svn rm |
| git checkout | 변경 취소 | svn revert |
| git reset | 변경 취소 | svn revert |
| git branch | 브랜치 생성 | svn copy |
| git checkout | 브랜치 교체 | svn switch |
| git merge | 병합 | svn merge |
| git tag | 태그 생성 | svn copy |
| git pull | 업데이트 | svn update |
| git fetch | 업데이트 | svn update |
| git push | 원격 저장소에 반영 | svn commit |
| gitignore | 제외 파일 리스트 | .svnignore |
정리하며
이 글을 정리하며 SVN과 Git의 차이 비교 중 SVN은 배우기가 쉽고 Git은 배우기가 어렵다는 내용이 자주 언급되었다. 하지만 개인적으로 무엇을 먼저 사용해보았는가에 따라 그 차이는 있을 수 있다고 생각하여 본문에 추가하지 않았다.
다만 이러한 차이까지 모두 포함하여 비교해 보았을 때, 정해진 기한, 자원 내 개발을 완료해야 하는 SI 프로젝트의 경우, 배우기 쉽고 관리가 용이하여 비용이 절감되고, 개발 완료 후 잦은 배포가 불필요하기 때문에 SVN을 사용한다. 반면 지속적인 개발로 코드의 안정성을 추구하는 포털, 서비스의 경우, 분산 관리 및 병렬 개발이 가능한 Git을 사용한다.
당연하게 사용했지만 개념과 차이, 그리고 사용 이유에 대해 다시 상세하게 알아보고 작성을 하다보니 생각보다 정리에 시간이 꽤 소요되었다. "당연하지"가 아닌 "왜"라는 의문을 가지며 개발하자.
참고
기본적인 개념에 대해서는 공식 사이트와 위키백과에 정리된 내용을 참고하였고, SVN과 Git의 비교에 대해서는 다양한 블로그, 기사, 사이트의 자료를 참고하였다. 여러 개의 사이트를 참고하였지만, 기본적인 개념은 동일하기에 모두 같은 이야기를 하고 있었다. 그 중 정리가 잘 되어 있는 사이트 몇 곳을 링크한다.
Git vs. SVN | What is the Difference?
Git vs SVN
SVN vs. Git: Which is right for you in 2020?
