포스트를 작성하게된 계기
평소에 프로젝트를 진행하며 깃허브를 사용하였을 때, 협업하는 팀원 별로 브랜치를 만들어서 사용하는 전략을 사용하였다. 그러다 보니 팀원들이 개발하고 있는 개발 내용을 한눈에 파악하기 어려웠고, 장기적으로는 유지보수에 안좋은 브랜치 전략인 것 같다는 생각을 하였다. 이번 포스트를 쓰면서 깃 브랜치 전략에 대해서 알아보고, 추후에 프로젝트를 진행할 때, 상황에 맞는 브랜치 전략을 택하여 프로젝트의 유지보수성을 높임이 목적이다.
Git Branch 전략의 필요성
브랜치 전략의 필요성은 다음과 같이 정리할 수 있다.
- 코드 관리의 효율성 - 여러 개발자가 동시에 개발하는데 충돌을 최소화
- 작업의 독립성 - 각각의 기능을 독립적으로 개발
- 안정성 유지 - 항상 동작 가능한 버전 확보 가능
- 코드 리뷰 및 품질 관리
- 배포 및 롤백의 용이성
Feature Branch
각 기능 별로 독립적인 브랜치를 생성하여 작업하는 전략이다.
서로 작업에 영향을 주지 않고 효율적으로 협업할 수 있다.
Feature Branch의 플로우는 아래와 같다.
- 먼저 새로 개발하는 기능에 대한 브랜치를 생성한다.
- 브랜치 이름은 해당 기능을 설명하는 명칭을 사용하고, 'feature/기능명'의 형식을 따른다.
git checkout -b feature/new_feature
- 새로운 브랜치에서 작업을 진행하고, 변경 내용을 커밋한다.
git add .git commit -m "커밋 메시지"
- 변경된 내용을 원격 저장소에 push한다.
git push origin feature/new_feature
- 기준 브랜치에 feature 브랜치를 머지한다. 머지 후 불필요한 feature 브랜치는 삭제한다.
git checkout maingit merge --no-ff feature/new_featuregit branch -d feature/new_feature
Github Flow
규모가 작거나 중간 크기의 프로젝트에 적합한 전략이다. 빠른 개발 주기와 지속적인 배포에 초점이 맞춰져있다.
Github Flow의 진행 방식은 아래와 같다.
- 기준 브랜치에서 새로운 브랜치를 생성한다. 브랜치 명은 작업 내용을 설명하는 명칭으로 명명한다.
- `git checkout -b new_feature``
- 변경 내용을 커밋한다.
git add .git commit -m "커밋 메시지"
- 변경된 내용을 원격 저장소에 push한다.
git push origin new_feature
- 깃허브에서 풀리퀘스트를 생성하여 코드 리뷰를 요청하고, 코드 리뷰 완료 후 기준 브랜치로 머지한다.
Git Flow
프로젝트의 코드 관리와 릴리스를 체계적으로 진행하는 방법론이다.
기본적으로 아래 5개 브랜치를 유지하고 있다.
- Master : 프로덕션 환경에서 배포되는 안정적인 코드를 위한 브랜치
- Develop : 개발 중인 코드 관리를 위한 브랜치
- Feature : 새로운 기능 개발을 위한 브랜치 (develop이 기준 브랜치)
- Release : 새로운 버전 릴리스를 준비하는 브랜치 (develop이 기준 브랜치)
- Hotfix : 긴급한 버그 수정을 위한 브랜치 (Master가 기준 브랜치)
진행 방식은 아래와 같다.
- Develop 브랜치에서 Feature 브랜치를 생성한다.
- 기능 개발을 완료한 후 Develop 브랜치로 머지한다.
- Relesate 준비를 한다.
- Develop 브랜치에서 Release 브랜치를 생성하고, 버전 번호 부여, 문서 작업 등 릴리스와 관련된 작업을 진행한다.
- Release가 확정되면, Master 브랜치로 머지하고, 커밋에 태그로 릴리스 버전을 명시한다.
- Release 브랜치는 Developer 브랜치에도 머지해줘야합니다.
- 긴급한 버그가 생기면, Master로부터 Hotfix 브랜치를 생성하고 수정이 완료되면 Master와 머지한다.
언제 어떤 전략을 선택할지는 프로젝트 규모, 개발 팀의 구성, 개발 및 배포 주기, 코드 안정성에 따라 그에 맞게 선택하는 것이 좋다.
각 브랜치 전략에 대한 특징을 정리해보면 다음과 같다.
| 전략 | 특징 |
|---|---|
| Feature Branch | 규모가 작거나 중간 크기의 프로젝트에 적합,서로 다른 기능 개발이 동시에 이루어질 때 적합, 간단한 브랜치 전략을 사용하여 협업하고 싶을 때 |
| Github Flow | 규모가 작거나 중간 크기의 프로젝트에 적합, 지속적인 통합 및 배포를 원할 때 유용, 빠른 개발 주기와 간단한 브랜치 전략을 선호할 때 적합 |
| Git Flow | 규모가 크고 복잡한 프로젝트에 적합, 여러 개발자들이 협업하고, 다양한 기능 및 릴리스가 동시에 관리되어야 할 때 유용, 코드의 안정성과 릴리스 관리를 체계적으로 수행하고자 할 때 적합 |
브랜치 전략에 대해서 공부해보니, 안정적인 코드 관리를 위해서는 Git Flow 방식이 적합할 것 같고, 간단한 프로젝트에서는 코드리뷰를 겸할 수 있는 Github Flow 방식이 적합할 것 같다. 이번 포스트를 작성하면서 배운 점으로 다음 프로젝트를 진행할 때에는 Github Flow 방식으로 진행해볼 계획이다.
