svn을 사용하여 패키지 소프트웨어를 개발하고 배포하는 일을 하고 있습니다. 그런데, 요즘은 대부분 git을 사용합니다. git으로 옮기고 싶은데, svn의 브랜치 전략과 git의 브랜치 전략이 다양하게 있어서 어떤 것을 써야 할지 잘 모르겠습니다. 그래서, svn을 사용하여 패키지 소프트웨어를 개발하던 조직이 git이나 github를 사용할 때 어떤 브랜치 전략을 사용하는 것이 좋을지 처음부터 알아보았습니다.
Table Of Contents
브랜치(Branch)란 무엇인가요?
브랜치는 독립적으로 작업을 수행하기 위한 개념입니다. 각각의 브랜치는 다른 브랜치와 독립적으로 작업되므로 여러 작업을 동시에 진행할 수 있습니다. 그 뿐 아니라, 브랜치는 특정 배포 버전을 위해서 사용될 수도 있습니다. 예를 들어, 1.0 버전의 배포를 관리하기 위해서 1.0 브랜치를 생성할 수 있습니다.
소프트웨어 개발에서 개발자들은 함께 작업하면서 동일한 소스코드를 공유하고 수정합니다. 한 사람은 버그를 수정하고, 또 다른 사람은 새로운 기능을 개발할 수 있습니다. 여러 사람이 동시에 작업할 때 각자의 작업을 분리하거나 위해 브랜치를 사용할 수 있습니다.
그뿐 아니라, 소프트웨어 배포 버전별로 서로 다른 코드를 유지보수 할 수도 있습니다. 이전 배포 버전에 해당하는 소스코드를 찾고 유지보수하기 위해서 배포 정책에 따른 버전을 따로 관리할 필요가 있습니다. 이를 위해서도 브랜치를 사용합니다.
svn과 git
SVN(Subversion)과 Git은 모두 버전 관리 시스템이지만, 주요 차이점은 다음과 같다고 합니다.
- 저장소의 유형: SVN은 중앙 집중식 버전 관리 시스템이며, 모든 변경 사항이 중앙 서버에 저장됩니다. 반면에 Git은 분산 버전 관리 시스템으로, 각 개발자의 로컬 시스템에 전체 코드베이스의 복사본이 저장됩니다. 이로 인해 Git은 네트워크 오프라인 상황에서도 코드를 관리할 수 있으며, 중앙 서버에 문제가 발생해도 로컬 저장소를 이용하여 복구가 가능합니다.
- 데이터 관리 방식: SVN은 델타 방식으로 소스를 관리하며, 이전 버전과 현재 버전 간의 차이점만을 저장합니다. 이 방식은 데이터의 용량을 줄일 수 있지만, 특정 시점에서의 파일을 형성하려면 이전에 관리했던 시점을 모두 훑으면서 차이점을 모두 계산해야 합니다. 반면에 Git은 스냅샷 방식으로 소스를 관리하며, 데이터의 현재 상태 자체를 하나의 시점으로 저장합니다. 이 방식은 저장, 읽기 등의 액션에 드는 리소스가 가볍지만, 데이터를 많이 사용해야 한다는 단점이 있습니다.
- 브랜치 관리: Git은 브랜치 생성과 병합이 매우 쉽고 빠르며, 이는 여러 개발자가 동시에 다양한 기능을 개발할 때 매우 유용합니다. 반면 SVN에서는 브랜치를 다루는 것이 상대적으로 성능이 느리다고 합니다.
가장 중요한 것은, Git은 현재 가장 널리 사용되는 버전 관리 시스템 중 하나입니다.
사실, 위의 내용들 중 SVN과 Git이 특별히 큰 차이가 있는 부분을 찾기는 쉽지 않습니다. 사용자 입장에서는 그냥 소스 버전관리 시스템일 뿐입니다. 오히려 데이터 관리방식은 svn이 더 적은 용량을 사용하기 때문에 좋아 보이기도 합니다. 그러나, 대세는 git과 github입니다.
결국 이런 차이점은 크게 중요하지 않고 앞으로는 git을 쓰는 게 일반적이라고 보시면 됩니다.
그러면, svn을 사용하여 패키지 소프트웨어 브랜치를 관리하던 조직이 git이나 github로 전향하려고 할 때 어떤 브랜치 전략을 사용하는 것이 좋을지 고민해 보게 되었습니다.
사실, git을 직접 구축하는 것도 좋지만, github가 잘 되어있으므로 github로 옮길 때를 고려해 보려고 합니다.
패키지 소프트웨어 회사의 SVN 브랜치 전략
패키지 소프트웨어를 개발하는 회사는 버전을 관리합니다. 그중 오래된 회사는 svn으로 소스코드의 버전을 관리하고 있습니다. svn에서 주로 사용하는 브랜치 관리 전략은 다음과 같습니다.
SVN(Subversion)에서는 주로 다음과 같은 브랜치 관리 전략을 사용합니다.
- Trunk-Based Development: 이 전략에서는 모든 개발자가 trunk라는 메인 브랜치에서 작업을 진행합니다. 새로운 기능이나 버그 수정 등의 작업이 완료되면 해당 변경 사항을 trunk에 병합(merge)합니다.
- Feature Branches: 이 전략에서는 각 기능마다 별도의 브랜치를 생성하여 작업을 진행합니다. 기능 개발이 완료되면 해당 브랜치를 trunk에 병합합니다. 이 방식은 각 기능을 독립적으로 개발하고 테스트할 수 있어 복잡한 프로젝트에서 유용합니다.
- Release Branches: 이 전략에서는 배포를 위한 별도의 브랜치를 생성합니다. 이 브랜치에서는 배포에 필요한 마지막 수정 사항을 처리하고, 배포하고 유지보수 합니다.
trunk : 소스의 주 개발 작업을 진행하는 브랜치입니다.
branches : 소스의 버전별 릴리즈를 유지보수하고, trunk 기반으로 신규 기능 등을 개발할 경우 사용하는 브랜치입니다.
tags : 릴리즈된 소스를 관리하기 쉽게 따로 보관하는 폴더인데, 특정 소스코드에 꼬리표를 붙여놓는다고 생각하시는 것이 쉽습니다.
이러한 브랜치 전략은 팀의 작업 흐름, 프로젝트의 규모, 배포 주기 등에 따라 선택됩니다. 따라서 본인이 속한 회사에 가장 적합한 전략을 선택하면 됩니다.
하지만, 일반적으로 과거 배포 버전을 수정하지 않고 지속적으로 관리해야 하는 패키지 소프트웨어 개발사의 경우 위와 같은 형태로 svn을 사용하고 있습니다.
Git의 브랜치 전략
Git에서는 주로 세 가지 브랜치 전략을 사용합니다: Git Flow, GitHub Flow, 그리고 GitLab Flow입니다.
- Git Flow: 이 전략은 두 개의 메인 브랜치(master, develop)와 세 개의 보조 브랜치(feature, release, hotfix)를 사용합니다.
- 메인 브랜치는 항상 유지되며, master 브랜치는 배포 가능한 상태만을 관리하고, develop 브랜치는 다음에 배포할 것을 개발하는 브랜치입니다.
- 보조 브랜치는 특정 기능을 개발하거나 버그를 수정하는 등의 작업을 완료하면 사라집니다.
- 작업 순서
- master에서 develop을 분기
- 개발과정은 develop 브랜치에 자유롭게 커밋
- 특정 기능 구현이 있는 경우 develop에서 feature-* 브랜치를 분기
- 배포를 준비하기 위해 develop에서 release-* 브랜치를 분기
- 테스트를 진행하면서 발생하는 버그 수정은 release-* 브랜치에 직접 수정 및 반영
- 테스트가 완료되면 release 브랜치를 master와 develop에 merge
-
브랜치 이름별 특징과 용도는 다음과 같습니다.
브랜치 특징 용도 master 제품으로 출시될 수 있는 브랜치 출시 버전 관리 develop 다음 출시 버전을 개발하는 브랜치 개발 중인 버전 관리 feature 단위 기능을 개발하는 브랜치 기능 개발 release 이번 출시 버전을 준비하는 브랜치 배포 준비 및 테스트 hotfix 출시 버전에서 발생한 크리티컬한 버그를 긴급 수정하는 브랜치 버그 수정 
- GitHub Flow: 이 전략은 브랜치가 단순해서 이해하기 쉽습니다. 배포 가능한 상태를 가진 master 브랜치를 둔 후, 기능 개발이나 버그 픽스 등의 이유로 브랜치를 만들어 개발한 후 merge합니다.
- 작업흐름
- master에서 새로운 브랜치를 분기
- 기능 개발 완료 시 master에 Pull Request 생성
- Pull Request에서 코드 리뷰
- 리뷰 및 테스트 완료 시 master 브랜치로 merge
- master 브랜치에서 배포(자동 배포를 사용 시 더욱 편함)
- Git Flow에 비해 굉장히 간단함
- master 브랜치와 pull request 방식을 활용하여 굉장히 단순한 형태
- 수시로 배포가 일어나고, CI/CD 파이프라인이 구성되어 있는 프로젝트에 유용
브랜치 특징 용도 master 프로젝트의 기둥, 제품으로 출시될 수 있는 브랜치 프로젝트를 product에 배포할 때 사용 새로운 브랜치 새로운 일을 시작하기 위해 만드는 브랜치, 항상 master에서 분기, Git Flow와는 다르게 feature, release, develop 등을 나누지 않음 새로운 기능 개발, 코드 공유 및 리뷰, master 브랜치로 반영 요구
- GitLab Flow: 이 전략은 Git Flow와 GitHub Flow의 장점을 결합한 방식입니다. GitLab Flow는 master 브랜치에서 브랜치를 만들어 개발하고, 개발이 완료되면 다시 master 브랜치로 merge합니다. 이 방식은 CI/CD(Continuous Integration/Continuous Deployment)와 잘 맞습니다.
- 작업절차
- Github Flow에서 배포를 위해 추가된 Production 브랜치와 테스트를 위한 Pre-production 브랜치 빼고 동일
-
브랜치 특징 용도 master Gitlab Flow의 master 브랜치는 production 브랜치로 병합됨 Git Flow의 master 브랜치 역할과 같음 pre-production production으로 넘어가기 전의 브랜치, 테스트 등을 담당 Production 브랜치로 넘어가기 전에 테스트를 진행하는 브랜치 production 배포만을 담당 Production 브랜치가 존재
각 브랜치 전략은 팀의 작업 흐름, 프로젝트의 규모, 배포 주기 등에 따라 선택됩니다. 따라서 가장 적합한 전략을 선택하는 것이 중요하고, 반드시 위의 세 가지와 동일하게 가져갈 필요는 없습니다. 상황에 따라 조직에 적합한 방법으로 수정해도 무방합니다.
패키지 소프트웨어 관리를 위한 svn to github 브랜치 전략
앞에서 살펴본 svn 패키지 소프트웨어를 관리하기 위해서 github에서 사용하기 좋은 방법에 대해서 설명하겠습니다.
github는 기본적으로 github flow가 이해하기 쉽고 master(main) 브랜치를 관리하는데 용이합니다. 그러므로, 기본적으로 github flow를 따릅니다.
거기에 패키지 소프트웨어는 필연적으로 특정 릴리즈를 따로 관리하고 유지보수하게 됩니다.
그렇기 때문에 gitlab flow처럼 배포를 담당하는 production 브랜치가 필요합니다. 그러므로, github flow를 기본적으로 사용하고 production 브랜치를 관리하는 gitlab flow가 가장 적합하다고 볼 수 있겠습니다.
gitlab flow는 기존의 패키지 소프트웨어를 관리하던 방식과 가장 유사하게 github를 사용할 수 있는 방식입니다.
오늘은 git의 버전 관리를 위한 브랜치 정책을 알아보았습니다. 기존의 svn을 사용하시던 분들은 git의 다양한 기능 및 개념들과 복잡한 부분이 많아져서 혼란스러운 분들이 있으실 것 같습니다. 하지만, 소스코드 형상을 관리한다는 점은 크게 다르지 않고 git의 모든 기능을 다 사용할 필요도 없으니, 너무 어렵게 생각하지 마시고 편한 방식으로 사용하시면 될 것 같습니다.
'IT' 카테고리의 다른 글
| 우분투(Ubuntu) 버전 정보 확인하기 (0) | 2024.02.28 |
|---|---|
| GitHub 브랜치 생성 및 작업 방법 - GUI와 CLI (0) | 2024.02.26 |
| 구글 스프레드시트(엑셀) 확장 프로그램 설치하기 - 프로젝트 관리도구 WBS, 간트차트 (0) | 2024.02.22 |
| 리눅스에서 git diff를 GUI로 보는 법 - vscode, tkdiff, meld 사용법 (35) | 2024.02.21 |
| 우분투 Linux에서 meld 설치하기 (1) | 2024.02.21 |
