Today I Learned
(25.02.26) Git Flow 명령어와 활용 정리
Genie;
2025. 2. 26. 17:01
실제 회사의 개발환경에서 macOS와 Linux기반으로 개발이 진행되다 보니 일반적인 깃을 사용하기 보다는 git flow를 적극적으로 활용하는 개발 규칙이 있어 급하게 git flow에 대해서 공부하고 실습하면서 중요한 내용들을 정리했다.
Git Flow
- Git을 활용한 브랜치 전략(branching strategy), 소프트웨어 개발 프로젝트에서 효율적인 브랜치 관리를 위한 Workflow 모델
- 기능 개발, 버그 수정, 배포 등을 체계적으로 관리하는 방법
- 개발, 배포, 버그 픽스 등의 브랜치를 생성하고 병합하는 과정에서 규칙에 맞춰 빠르게 체계적으로 관리할 수 있도록 할 수 있음
- 안정적인 배포
- 병렬 개발
- 버전 관리
주요 Branch
| 브랜치 | 역할 | 생성 시점 |
| main | 제품으로 출시되는 브랜치 | 배포할 때 |
| develop | 개발 중인 최신 코드가 모이는 브랜치 | 기능 개발 완료 후 병합 |
| feature/* | 새로운 기능을 개발하는 브랜치 | 새로운 기능이 필요할 때 |
| release/* | 배포 전 최종 테스트를 수행하는 브랜치 | 일정 기간 동안 안정화가 필요할 때 |
| hotfix/* | 배포 후 긴급한 버그를 수정하는 브랜치 | 운영 환경에서 심각한 버그 발생 시 |
git flow 설치
- macOS (Homebrew 사용)
brew install git-flow-avh
- Ubuntu/Debian (APT 사용)
sudo apt-get install git-flow
- Windows
- 개발자가 macO와 Linux기반을 해버려서 사용하기 매우 까다로움, 따라서 차라리 PowerShell에서 관리자 권한으로 Chocolatey 패키지 관리자를 통해서 툴 째로 설치를 해야함
- 이 밖에 윈도우일 경우 설치가 복잡해서 많은 방법을 사용할 수 있음
choco install git-flow-avh
git flow 준비git flow init
$ git flow init
Which branch should be used for production releases? [main]
Which branch should be used for development? [develop]
How to name your feature branches? [feature/]
How to name your release branches? [release/]
How to name your hotfix branches? [hotfix/]
How to name your support branches? [no support branches]
- 기본적으로 위에서 순서대로 사용자의 규칙에 따라서 수정을 할 수 있음
- 각 질문에 순서대로 답을 하면 바로 설정을 할 수 있음
기능 개발 feature/*
- develop (또는 dev) 브랜치에서 분기되어서 개발이 진행되는 개발
- 완료 시, 병합하거나 다른 개발자를 위해 publish 할 수 있음
| 단계 | 명령어 | 설명 |
| 기능 브랜치 시작 | git flow feature start <feature-name> | develop 브랜치에서 새로운 feature 브랜치 생성 |
| 기능 개발(일반적인 | git add . → git commit -m "작업 내용" | 파일을 추가하고 커밋 (일반적인 커밋) |
| 기능 개발 완료 | git flow feature finish <feature-name> | feature 브랜치를 develop 브랜치에 병합 후 삭제 |
| 리모트 저장소에 푸시 (공유용) | git flow feature publish <feature-name> | 협업을 위해 feature 브랜치를 원격 저장소에 업로드 |
| 병합된 코드 푸시 | git flow feature pull origin <feature-name> | 다른 팀원이 원격 저장소에서 feature 브랜치를 가져옴 |
- 여기서 git flow feature publish를 사용하면 팀원과 기능 브랜치를 쉽게 공유할 수 있는 부분에 있어서 push 와 똑같지만, 일련의 git flow 패턴을 사용하기 위해서 구분함
- git flow feature publish는 Git Flow의 표준적인 명령어이며, 내부적으로 git push를 실행하는 편의 기능
기능 배포 release/*
| 단계 | 명령어 | 설명 |
| 릴리즈 브랜치 시작 | git flow release start <version> | develop 브랜치에서 새로운 release 브랜치 생성 (release/<version>) |
| 릴리즈 브랜치 공유 (선택) | git flow release publish <version> | 다른 팀원과 공유하기 위해 원격 저장소에 release 브랜치를 푸시 |
| 버그 수정 및 테스트 | git add →.git commit -m "수정 내용" | 테스트 및 버그 수정 후 커밋 |
| 버전 이동 및 추적 | git flow release track <version> | 이미 생성된 release 브랜치를 추적, 특정 버전으로 돌아가 다른 작업과 변경사항을 수정 가능 |
| 릴리즈 완료 및 병합 | git flow release finish <version> | release 브랜치를 main과 develop에 병합 후 태그 생성 및 삭제 |
| 태그 푸시 (선택) | git push origin --tags | finish 명령어로 생성된 태그를 원격 저장소에 푸시 |
| 병합된 코드 푸시 | git push origin main / git push origin develop | main과 develop 브랜치를 원격 저장소에 푸시 |
- 릴리즈를 완료한 후 병합한 다음, git push origin --tags 을 진행해서 태그를 repository에 올릴 수 다는 것이 좋음
- finish 과정에서 태그(버전 번호) 에 해당하는 내용을 기입하는 부분이 git flow를 통해서 진행이 가능
- track 과정은 이미 finish 가 진행이 되었으면 진행할 수 없음
- 일종의 switch checkout과 같은 의미
- 즉 모든 버전은 합쳐지기 전에 각 릴리즈 버전마다 버그 브랜치가 존재해야한다는 것
핫픽스 hotfix/*
| 단계 | 명령어 | 설명 |
| 핫픽스 브랜치 시작 | git flow hotfix start <version> | main 브랜치에서 새로운 hotfix 브랜치 생성 (hotfix/<version>) |
| 핫픽스 브랜치 작업 | git add →.git commit -m "수정 내용" | 수정 사항을 적용하고 커밋 |
| 핫픽스 브랜치 공유 (선택) | git flow hotfix publish <version> | 다른 팀원과 공유하기 위해 hotfix 브랜치를 원격 저장소에 푸시 |
| 핫픽스 완료 및 병합 | git flow hotfix finish <version> | hotfix 브랜치를 main과 develop에 병합 후 태그 생성 및 삭제 |
| 태그 푸시 (선택) | git push origin --tags | finish 명령어로 생성된 태그를 원격 저장소에 푸시 |
| 병합된 코드 푸시 | git push origin maingit push origin develop | main과 develop 브랜치를 원격 저장소에 푸시 |
- 긴급한 버그 픽스라는 것과 달리 feature과 release와 거의 유사
- 버전은 release일 경우에는 1.0 / 1.0.0 로 버저닝이 되었다면, hotflix일 경우에는 minor 숫자를 증가시켜 1.1 / 1.0.1 로 버전을 지정하긴 함
push 와 pull 또는 branch 명령어를 통해서 수동으로 분기하고 merge한 상황에서 git flow의 협업에서의 개발 제품의 deploy를 직관적으로 체계적으로 관리하는 툴은 매력적으로 보였다.
대부분의 필드에서도 활용하는 만큼 실제 본인의 개발 OS는 윈도우이기 때문에 쉽게 환경 설정에서는 문제가 있을 수 있지만, 빠르게 구성해서 실습과 개발에 적극적으로 활용할 수 있어야할 것이다.
