안녕하세요. 이번 시리즈에서는 Git flow(깃 플로우)에 대해서 알아볼게요. Git flow를 알기 전에 Git에 대해서 먼저 알아야 해요.
서비스, 커머스 기타 등등의 많은 회사들에서 대부분 사용하고 있는 툴이기 때문에 Git과 Git Flow에 대해서 설명해 볼게요.
Git의 필요성
Git은 분산 버전 관리 시스템(DVCS)으로, 소프트웨어 개발에서 소스 코드의 변경 이력을 관리하는 데 사용됩니다. 과거에는 SVN과 같은 툴을 많이 사용했으나, 협업에 용의 하고 코드 통합이 편하기에 요즘은 Git을 많이 사용하고 있습니다. Git을 사용하는 주된 이유는 다음과 같습니다.
버전 관리
Git은 소스코드의 모든 변경 사항을 추적할 수 있습니다. 각 커밋(commit)은 변경된 내용을 저장하여 언제든지 이전 버전으로 되돌아갈 수 있습니다. 이는 코드 변경을 역사를 관리하고, 변경 이유를 이해하는 데 매우 유용합니다.
커밋 Commit
커밋이란 개발자가 수정한 코드를 반영하기 위한 작업을 의미합니다.
분산 개발
Git은 분산 버전 관리 시스템으로, 모든 개발자가 코드의 전체 히스토리를 로컬에 저장할 수 있습니다. 이는 중앙 서버에 대한 의존성을 줄이고, 오프라인 상태에서도 작업을 지속할 수 있게 합니다.
소스 코드 저장 장소
소스코드는 Working Directory, Staging Area, Local Repository, Remote Repository 위치에 저장됩니다. 파일을 수정하거나 생성 시 로컬 저장소 및 원격 저장소에 변경 사항들을 저장할 수 있습니다.
협업
Git은 여러 개발자가 동시에 같은 프로젝트에서 작업할 수 있도록 지원합니다. 브랜치를 사용하여 각각의 기능이나 버그 수정을 독립적으로 진행할 수 있으며, 이후 병합(merge)을 통해서 모든 작업들을 통합합니다.
코드 통합
다양한 브랜치를 사용하여 개발, 테스트, 배포 등의 단계를 분리할 수 있습니다. 이를 통해 코드의 안정성을 유지하면서도 새로운 기능을 지속적으로 추가할 수 있습니다.
Git Folw 소개
이번에는 Git Flow에 대해서 알아볼게요. Git Flow을 알기 위해서는 반드시 Git을 알아야 하기 때문에 위에서 간략히 설명드렸습니다. 그렇다면 Git Flow는 무엇일까요?
Git Flow란 무엇인가?
Git Flow는 Vincent Driessen이 제안한 Git 브랜치 모델로, 소프트웨어 개발 시 효율적인 브랜치 관리와 협업을 도와주는 워크플로우입니다. Git Flow는 프로젝트의 배포와 유지보수를 체계적으로 관리할 수 있게 해 주며, 복잡한 개발 과정에서도 깔끔하게 브랜치를 운영할 수 있도록 돕습니다.
Git Flow의 주요 목적
- 복잡한 소프트웨어 개발 프로세스를 체계화
- 명확한 브랜치 구조 제공
- 팀 협업 시 효율성 증대
Git Flow의 필요성
소프트웨어 개발이 점점 더 복잡해지면서, 코드 관리와 배포의 중요성이 커졌습니다. 특히 여러 개발자들이 동시에 작업할 때 브랜치 관리가 제대로 이루어지지 않으면 충돌이 발생하거나 코드 품질이 떨어질 수 있습니다. Git Flow는 이러한 문제를 해결하기 위해 다음과 같은 기능을 제공합니다:
- 분명한 브랜치 역할: 각 브랜치가 담당하는 역할이 명확하여 코드 관리가 용이합니다.
- 효율적인 협업: 여러 개발자들이 동시에 작업하더라도 충돌을 최소화할 수 있습니다.
- 안정적인 배포: 안정적인 버전을 유지하면서 새로운 기능을 개발할 수 있습니다.
Git Flow의 기본 개념
Git Flow는 다음과 같은 주요 브랜치들로 구성됩니다.
master 브랜치
실제 운영에 배포되는 브랜치를 의미합니다. master 브랜치는 무한한 수명을 가지고 있습니다. 만약에 Github를 사용해 봤다면 이 글자도 익숙할 것입니다. 그리고 최종 master 브랜치가 결국 배포에 사용되는 브랜치입니다.
개발자들이 변경사항을 develop 브랜치에 머지하고 여기서 최종적으로 안정적인 버전이 준비가 되었을 때, 모든 변경사항은 master 브랜치로 병합되어야 하며 보통은 릴리스 번호가 태그로 지정됩니다.
develop 브랜치
최신 개발 버전을 관리합니다. 모든 feature 브랜치의 개발이 끝나면 develop 브랜치에 머지됩니다.
develop 브랜치는 개발을 위한 브랜치라 생각하면 됩니다. 따라서 모든 feature 브랜치는 develop에서 만들어서 개발하고 다시 develop에 머지됩니다. 그래서 항상 develop 브랜치는 master 브랜치보다 많은 양의 소스가 병합되어 있습니다. 그리고 특정 시점이 되어 운영 배포가 될 시점에는 develop 브랜치에서 release 브랜치를 만들고 QA를 진행하며 수정된 사항들은 모두 다시 master, develop에 머지되어 버전을 관리합니다.
feature 브랜치
새로운 기능을 개발할 때 사용됩니다. feature 브랜치는 develop 브랜치에서 만들어집니다. 그리고 개발이 완성되면 다시 develop 브랜치에 머지됩니다.
feature 브랜치는 새로운 기능 개발을 위해 생성되는 브랜치입니다. 그래서 하나의 개발팀 내에서도 굉장히 많은 여러 feature 브랜치들이 만들어지고 진행됩니다. 브랜치는 만들 때는 보통 다음과 같은 이름으로 만들어집니다.
feature/[new feature name]
feature/[jira ticket number]
이렇게 만들면 현재 개발하고 있는 브랜치라고 알 수 있으며 어떤 기능을 개발하는지도 명확하게 파악이 가능합니다.
Jira ticket (지라 티켓)
지라 티켓은 지라라는 할 일(일감) 목록을 만들어 현재 개발의 진행사항을 파악할 수 있는 관리 툴입니다.
사이트 : https://www.atlassian.com/ko/software/jira
release 브랜치
실제 운영에 배포되기 위해서 배포 준비를 위한 브랜치입니다. release 브랜치는 develop 브랜치에서 생성되며 develop 브랜치와 master 브랜치에 머지됩니다.
release 브랜치는 새로운 배포를 지원합니다. 배포전 마지막으로 수정 작업을 허용하며, 사소한 버그 수정 및 메타데이터 준비를 하는 브랜치입니다. 보통의 release 브랜치는 만들어질 때 배포 버전 번호를 할당합니다. 따라서 현재 릴리즈 버전이 어떤 버전인지를 구분할 수 있는 브랜치입니다.
hotfix 브랜치
긴급 버그 수정을 위한 브랜치입니다. 실제 배포가 진행되어 master 브랜치에서 운영 배포가 일어난 이후에 문제가 발생했고 바로 수정을 해야 하는 부분이 발생했다면 hotfix 브랜치를 생성하며 이때 master 브랜치 기준으로 만들게 됩니다.
master에서 만들어진 hotfix 브랜치는 버그를 수정하고 테스트를 완료했을 경우 다시 master 브랜치에 머지해 줍니다. 그리고 동일한 소스를 develop 브랜치에도 머지해 줍니다. develop 브랜치에 머지해 주는 이유는 hotfixs는 master에서 분기해서 수정되었기 때문에 develop에 머지될 조건이 없습니다. 따라서 반드시 수정된 소스는 develop 브랜치에 머지가 필요합니다.
이러한 브랜치 모델을 통해 프로젝트의 모든 단계에서 명확한 브랜치 관리를 할 수 있습니다.
Git Flow의 장점
명확한 브랜치 역할
각 브랜치가 명확한 역할을 갖고 있어 관리가 용이합니다. master, develop, feature, release, hotfix와 같이 명확한 이름들이 존재하고 역할이 존재합니다. 따라서 협업을 하는 과정에서 이 용어들만 알고 있다면 누가 어떤 작업을 진행하고 있고, 현재 우리 서버에 배포된 버전이 어떤 버전인지도 쉽게 파악할 수 있습니다.
효율적인 협업
개발자들이 각각의 브랜치에서 독립적으로 작업할 수 있습니다. master 혹은 develop에서 직업 작업하는 과정은 없으며 이 두 브랜치는 머지된 커밋 로그만 남을 것입니다. 그리고 서로의 작업에 영향을 주지 않으면서도 개발해 나갈 수 있는 장점이 있습니다.
물론 동일한 소스코드를 수정하면 충돌을 해결하는 과정이 존재하지만 이 부분도 다른 개발자가 개발한 부분은 손대지 않고 내 부분만을 해결하면 되기 때문에 어렵지 않게 진행할 수 있습니다.
안정적인 배포
안정적인 버전을 유지하면서 새로운 기능을 개발할 수 있습니다. 배포는 무조건 master 브랜치에서만 진행하기 때문에 최종 버전 관리가 가능하고 롤백도 가능합니다. 또한, 배포 버전을 만들기 위해 최종 확인하는 release 브랜치가 있으며 현재 기능개발하는 브랜치는 어느 브랜치에도 영향을 주지 않습니다.
Git Flow의 단점
초기 설정이 복잡
Git Flow를 처음 설정할 때 약간의 복잡함이 있습니다. 하지만 간단한 설치만으로도 기본 5개의 브랜치를 사용할 수 있으며 툴이 존재하기 때문에 크게 복잡하지는 않습니다.
작은 프로젝트에는 과할 수 있음
작은 프로젝트에서는 필요 이상의 복잡성을 초래할 수 있습니다. 간단히 develop과 master 브랜치만으로 개발해도 되는 부분이지만 Git Flow를 지켜가면서 개발하기에는 과한 스펙일 수 있습니다.
참고자료
Vincent Driessen의 Git Flow 소개 글
A successful Git branching model
In this post I present a Git branching strategy for developing and releasing software as I’ve used it in many of my projects, and which has turned out to be very successful.
nvie.com
git-flow cheatsheet
danielkummer.github.io
마무리
이번 포스팅에서는 Git과 Git Flow에 대해서 알아보았어요. 가장 기본은 Git입니다. Git을 사용할 수 있어야 관리할 수 있는 Git Flow를 통해서 조금 더 쉽게 Git의 브랜치들을 관리할 수 있습니다.
간단히 이전 글들에서 Git에 대해서 포스팅을 해 두었습니다.
2021.03.19 - [쿤즈 DevTool/Git] - [Git] git 버전, 환경설정, 초기화, 삭제하기
2021.03.19 - [쿤즈 DevTool/Git] - [Git] git 에 파일 추가하는 방법 git add
2021.04.01 - [쿤즈 DevTool/Git] - [Git] 여러사람이 함께 작업하는 브랜치 git branch
2021.03.31 - [쿤즈 DevTool/Git] - [Git] 원격저장소(GitHub)에서 내려받기 git pull
2021.03.31 - [쿤즈 DevTool/Git] - [Git] 원격저장소(GitHub)에 소스 업로드 git push
2021.03.29 - [쿤즈 DevTool/Git] - [Git] GitHub에 git push 하는 방법 (feat. GitHub 가입부터 키 생성까지)
2021.03.24 - [쿤즈 DevTool/Git] - [Git] Commit 메세지 수정하기 amend commit
2021.03.22 - [쿤즈 DevTool/Git] - [Git] 소스관리 파일 커밋 git commit
그리고 Git Flow와 연결하여 같이 관리하는 방법들을 포스팅해 나갈 예정입니다.
이 블로그 시리즈를 통해 여러분은 Git Flow의 기본 개념을 이해하고, 실습을 통해 실제 프로젝트에 적용하는 방법을 배우게 될 것입니다. 다음 챕터에서는 Git Flow의 설치 및 설정 방법에 대해 자세히 알아보겠습니다.
'쿤즈 Dev > Git' 카테고리의 다른 글
| [Git Flow] Git Flow 브랜치 모델 (0) | 2024.06.15 |
|---|---|
| [Git Flow] Git Flow 설치 및 설정 (0) | 2024.06.10 |
| [Git] 여러사람이 함께 작업하는 브랜치 git branch (0) | 2021.04.05 |
| [Git] 원격저장소(GitHub)에서 내려받기 git pull (0) | 2021.04.04 |
| [Git] 원격저장소(GitHub)에 소스 업로드 git push (0) | 2021.04.02 |
댓글