[Version Control] SVN, Git, GitHub, GitLab

이번 포스트에서는 버전관리를 쉽게 할 수 있도록 도와주는 Software에 대해 알아볼 예정입니다.

보통 SVN, Git, Github, GitLab을 많이 사용하죠. 이들에 대해 간단하게 정리해 봅니다.

 

 

우선, SVN, Git, GitHub, GitLab... 이들은 왜 사용할까요?

간단하게 말하면, 버전관리를 효율적으로 하기 위해 사용합니다. 작업을 했는데 새로운 작업물이 안드로메다로 가버려서 이전 작업으로 되돌리고 싶을 때, 또는 나 이외의 다른 개발자들과 협업을 하면서 작업물을 관리해야 할 때, 그리고 아주 단순하게는 프로젝트 파일을 불특정 다수와 공유하고 싶을 때 등등, 이들을 활용하면 작업을 좀 더 원활하게 수행할 수 있습니다.

 

그럼 이제 이들 각각에 대해 알아보도록 하겠습니다.

 

SVN (Subversion)

Apache Subversion

 

SVN은 아파치 라이선스를 보유한 2000년대 초반에 발표된 버전 관리 툴로, 저장소를 만들어 그곳에 소스를 저장하여 소스 중복과 같은 문제들을 해결하기 위한 형상관리/소스 관리 툴입니다. 이를 통해 여러 명에서 작업하는 프로젝트의 버전 관리나 각자 만든 소스의 통합과 같은 문제를 해결할 수 있습니다.

출시 이후에 가장 대중적으로 사용되었던 프로그램이며, Source의 저장소를 Server로 두고, 작업하는 PC를 Client로 연결하여 사용하는 방식입니다.

리눅스에는 Default로 설치되어 있을 정도로 많이 사용되었습니다. svnserver를 설치해 Server 역할을 수행하고 svn client를 설치하여 Client PC로 사용할 수 있습니다. 즉 간편하게 사용할 수 있다는 장점이 있습니다.

 

SVN의 전반적인 사용 Flow는 다음과 같습니다.

SVN Flow

최초로 서버 소스를 Checkout 합니다. 그리고 Source를 작성하거나 수정합니다. Commit 할 파일을 Add 하고 Update를 통해 Repository에 새로운 파일이 없는지 확인합니다. Update과정에서 Conflick가 발생되면 해결하고 수정 후 Resolve를 해줍니다. 그리고 최종적으로 Commit을 하여 Repository에 파일을 등록합니다.

뭐... Git이나 Github나 SVN이나 큰 흐름은 비슷합니다.ㅎ

 

위 그림에서 나오는 몇 가지 명칭에 대해 알아보겠습니다.

Trunk는 메인 개발 소스를 의미하며, 개발 소스를 Commit 했을 때 여러 개발 소스들이 모이는 곳입니다. Branch는 Trunk에서 분기된 개발 소스이며 실험적인 기능을 추가하거나 출시를 위한 안정화 버전을 작업할 때 주로 사용됩니다. Tag는 특정 시점에서 프로젝트의 Snap Shot을 찍어두는 것입니다. Branch와 Tag는 동일하지만, Tag는 관례적으로 더 이상 개발하지 않고 어떤 버전으로 Fix 해 놓을 때 사용합니다.

 

그러나, SVN은 조금은 유행이 지난 버전 관리 툴이 되어버렸습니다. 2010년대 초반, Android의 출현 이후로 버전 관리 도구의 트렌드가 바뀌어 버렸습니다.

 

 

Git

Git

 

Git은 2005년 리눅스 창시자인 리누스 토발즈가 처음 출시한 프로그램입니다. 출시는 2005년에 하였으나, 빛을 보기 시작한 것은 2010년대 정도부터입니다. 앞서 언급한 SVN을 잇는 버전 관리 툴이 되었지요.

 

최근 개발 구조는 하단과 같은 마이크로 서비스 아키텍처(Micro Service Architecture, MSA)를 따릅니다. 하나의 소스에 대규모로 붙어서 작업하는 것이 아니라 개발자마다 각자 맡은 프로젝트를 진행하는 경우가 많습니다. 그리고 이들은 합쳐서 최종적으로 서비스를 배포하게 됩니다.

Micro Service Architecture, MSA

또한 Open Source가 하나의 트렌드로 자리 잡으면서 개발을 진행하면서 유사 프로젝트를 찾아 활용하는 경우가 많아졌습니다. 이러한 개발 추세의 변화 속에서 Git이 SVN의 자리를 침범하게 되었습니다. 

 

Git은  SVN에 비해 기능도 많고 사용하기 까다로운 부분이 있습니다. 그러나 Windows, Linux, Mac 등 OS와 관계없이 어디어서든지 사용이 가능할 뿐만 아니라, 분산 기능과 확장성 때문에 최근 트렌드로 자리 잡게 되었습니다. SVN은 반드시 Remote Server를 두어야 했지만, Git은 작업을 진행하는 Local 자체가 Server가 될 수 있고 Client가 될 수도 있으며, Local이 Server가 될 수도 있고 Server도 Local이 될 수 있습니다. 또한 Branch와 Tag를 프로그래머 재량으로 Local에서 Commit 및 관리를 할 수 있습니다.

 

앞서 언급하였듯이 Git의 기능은 꽤 많습니다. 여기서 다루기에는 너무 양이 많으니, Git의 전반적인 Flow에 대해서만 간단하게 다뤄보도록 하겠습니다.

우선, 정말 기초적인 용어(Commit, Push, Branch, Fetch, Merge, Pull)에 대해 설명하도록 하겠습니다. Commit은 파일을 추가하거나 변경 내용을 저장소에 저장하는 작업을 의미합니다. Push는 파일을 추가하거나 변경 내용을 원격 저장소에 업로드하는 작업을 의미합니다. Branch는 병렬의 형태로 개발될 때, 여러 버전 관리를 위해 분기 지점을 나누고 다른 지점에 영향을 받지 않게 하여 같은 저장소에 각각의 버전으로 개발을 진행할 수 있도록 하는 것을 의미합니다. Fetch는 Local에는 없지만 원격 저장소에 올라가 있는 데이터를 모두 가져오는 것을 의미합니다. Merge는 현재 작업 중인 Branch에 병합할 Commit을 지정해서 병합하는 것을 의미합니다. Pull은 원격 저장소의 변경된 데이터를 가져와 다운로드받고 현재 작업하는 Local Branch와 자동으로 병합하는 작업을 의미합니다.

 

이제, Git의 사용 흐름에 대해 알아보도록 하겠습니다. 기본적으로 사용되는 구조는 다음과 같습니다.

저장소를 새로 만들거나, 이미 저장소가 있다면 복제합니다. 새로 만들어진 공간 또는 복제된 공간에서 작업을 수행합니다. 작업 공간에서 수행된 요소들을 Index에 추가해 줍니다. 이때 Index는 준비 영역이며, 최종 확정본을 만들기 전에 임시적으로 사용되는 영역이라고 생각하시면 됩니다. 모든 것이 완료되었고 이제 완벽하다고 생각되면 HEAD에 Commit을 합니다. 이로써 작업 공간에서의 확정본이 저장됩니다. 그러나 저장소에는 해당 내용이 적용되지 않았습니다. 저장소에도 수행된 결과물을 적용하고 싶다면 Push를 통해 저장할 수 있습니다.

위와 같은 흐름은 한 개의 Branch에서의 흐름이라고 생각하시면 됩니다. 만일 다른 Branch를 만들게 된다면 어떻게 될까요?

기본적으로 Repository를 생성하면 Master Branch가 생성됩니다. 만일 다른 Branch를 이용해 개발을 진행하고 싶다면 checkout을 통해 Branch를 생성하고 Branch들을 이동하면서 개발을 진행할 수 있습니다. 이때 이 Branch들은 저장소에 반영되지 않습니다. (반영을 위해서는 push를 해주어야 합니다.) 어떠한 Branch 개발이 완전히 마무리되었다면 merge를 수행하여 Master Branch와 병합합니다. 참고로 Pull 명령은 Fetch와 Merge가 합쳐진 명령어로 Local 저장소를 Remote 저장소에 맞춰 갱신할 때 사용합니다.

 

이 설명이 Git의 전부를 말해주진 않지만, 큰 틀에 대해서는 이해할 수 있을 것이라 생각됩니다.

그럼 이제, 클 맨 처음에 언급했던 SVN와 Git의 차이를 표로 정리해 보도록 하겠습니다. 내용은 다음과 같습니다.

	SVN	Git
사용법	간단함	다소 복잡
기능	간편한 기능 포함	다양한 기능 포함
프로세스	중앙 집중식	분산 관리식
소스 충돌 위험	충돌 가능성 매우 높음	권한 설정 -> 충돌 위험 감소
저장소 백업 여부	용이하지 못함	매우 용이함
다수 작업 관리	한계점 존재	분산작업으로 수행 가능
작업 내용 복구	불편함	Revision으로 복구가 편리함
Branch 생성	불편함	Local에서 Branch 및 Tag 생성이 편리함

작성하고 보니, Git의 장점이 월등히 높네요...ㅎㅎ

 

 

GitHub

GitHub: Let’s build from here

 

Git과 명칭이 비슷하기에 Github와의 차이점이 없을 것이라고 생각할 수 있을 것입니다. 그러나 Git은 리누스가 만들었고 Github는 Microsoft가 가지고 있습니다. 뭐.. 근데 이 정도의 차이점은 별로 의미가 없겠죠?ㅎ

Git을 사용하는 프로젝트를 지원하는 Web Hosting Service입니다. Git과 GitHub의 구조적인 차이점을 예로 들자면, Git은 PC속 어떠한 프로그램이라면, GitHub는 PC속 어떠한 프로그램의 Server를 의미합니다. 

기본적으로는 무료로 서비스를 제공하지만, 유료로 이용할 경우 다양한 기능들을 추가적으로 사용할 수 있습니다.

 

 

GitLab

The DevSecOps Platform

 

이 또한 Git, GitHub와 명칭이 비슷하지만, 물론 다릅니다.

GitLab은 Git 저장소와 이슈 추적 등의 기능을 가지고 있는 DevOps Platform으로, 나사, 골드만삭스, IBM, 소니, 알리바바, 스페이스 X 등 큰 단체에서 사용하고 있다고 합니다.

GitLab은 개인 또는 조직이 Git Repository의 내부 관리를 제공하는 데 사용할 수 있는 GitHub입니다. 쉽게 말하면 비공개된 GitHub라고 볼 수 있을 것입니다. GitLab은 중앙 서버에서 Git Repository를 관리합니다. GitLab은 Repository 또는 Project를 제어할 수 있고 공개 또는 비공개 여부를 무료로 결정할 수 있습니다.

뭐... 결론적으로 GitHub와 GitLab이 큰 차이점을 가지고 있진 않지만, 비용적인 문제 때문에 GitLab을 사용하는 경우가 많습니다. GitHub는 기본적으로 SaaS 형태로 제공되기에 월 $21 비용이 드는 Enterprise를 구매해야만 설치 버전을 사용할 수 있는 반면, GitLab은 무료로 모든 티어에서 SaaS형, 설치형을 선택적으로 사용할 수 있습니다. 

 

 

이처럼, 주로 사용되었던 그리고 주로 사용되고 있는 버전 관리 툴들에 대해 간략하게 알아보았습니다.

결국은 속해있는 집단에서 사용되는 프로그램을 사용하거나 트렌드를 따를 수밖에 없을 것입니다. 그래도 기본적인 큰 틀은 비슷하니 사용법에 익숙해지다 보면 자연스럽게 사용하게 되겠죠...?ㅎ

 

이번 포스트는 여기서 마무리하도록 하겠습니다.

향후, 각 툴의 사용법에 대해서도 다뤄보도록 하겠습니다.

 

---

 

PS. Git 사용에 대한 내용은 다음 포스트를 참고해 주세요.

[Git Bash]

[GitHub] GitHub를 통한 코드 관리 - 기초 (feat. Git Bash)