개발을 진행하면서 항상 메인 브랜치만 사용해 오다가, 어느 순간 “이렇게 해도 괜찮은 걸까?”하는 의문이 들었다..
실제로 협업 과정에서 메인 브랜치만 사용하다 보니 코드 충돌이 빈번하게 발생하는 문제를 겪었고
이런 경험을 바탕으로, 더 나은 협업 방법에 대해 고민해 보고자 해당 내용을 정리해 보았다!
1. Branch?
여러 개발자가 하나의 저장소에서 함께 작업할 때, 각자 다른 기능을 독립적으로 개발하고 수정할 수 있는 환경을 마련하는 것이 정말 중요하다. Git branch 전략은 바로 이런 협업 환경을 위해 팀원들이 일정한 규칙에 따라 브랜치를 생성하고 사용하도록 도와준다.
1-1. Git Branch 전략이 왜 필요하지?
- 개발 작업의 분리
- 각자 맡은 기능이나 수정 사항을 별도의 브랜치에서 진행하면, 서로의 작업이 섞이지 않아 안정적이다. 이런 방식은 특히 여러 기능을 동시에 개발할 때 유용하다.
- 문제 발생 시 빠른 대응
- 메인 브랜치에 바로 반영되지 않기 때문에 문제가 생겼을 때 쉽게 이전 상태로 복구할 수 있다.
- 협업 시 소통과 이해의 증진
- 모든 팀원이 동일한 규칙을 따르면, 작업의 흐름과 현재 진행 상황을 보다 쉽게 파악할 수 있어 팀원 간의 소통이 원활해진다.
2. 대표적인 Branch 전략: Git Flow와 GitHub Flow
Git branch 전략에는 여러 가지 방법이 있지만, 그 중에서 가장 많이 쓰이는 두 가지는 Git Flow와 GitHub Flow이다.
2-1. Git Flow
Git Flow는 기능 개발, 릴리즈 준비, 긴급 수정 등 다양한 상황에 맞춰 여러 브랜치를 활용하는 전략이다.
주요 특징은:
- 메인 브랜치
- master: 최종 배포 가능한 코드를 보관
- develop: 새로운 기능들이 통합되는 곳
- 보조 브랜치
- feature/*: 각 기능별 개발
- release/*: 릴리즈 준비 과정
- hotfix/*: 긴급 수정 사항 반영
이 전략은 대규모 프로젝트나 복잡한 릴리즈 관리를 필요로 할 때 유용하지만, 브랜치 전환과 병합 과정이 다소 복잡할 수 있다.
2-2. GitHub Flow
GitHub Flow는 보다 단순한 구조로,
특히 지속적 배포(CI/CD)를 하는 프로젝트에 적합하다.
- 메인 브랜치
- main 혹은 master: 항상 배포 가능한 상태 유지
- 기능 브랜치
- 새로운 기능이나 수정은 별도의 브랜치에서 작업 후, Pull Request(PR)를 통해 코드 리뷰와 테스트를 거쳐 메인 브랜치에 병합
간결하고 빠른 배포 주기를 지원하는 GitHub Flow는 소규모 프로젝트나 빠른 피드백을 원하는 팀에 적합하다.
3. 선택 기준
선택 기준 Git Flow GitHub Flow
| 프로젝트의 규모와 복잡성 | 기능이 많고 복잡하며 릴리즈 관리가 중요한 경우에 적합 | 기능이 단순하거나 빠른 배포가 중요한 프로젝트에 적합 |
| 팀의 협업 방식 | 체계적인 릴리즈 관리와 단계별 검증이 필요한 팀에 적합 | 코드 리뷰와 신속한 피드백이 중요한 팀에 적합 (PR 중심) |
| 배포 주기와 관리 방식 | 릴리즈 시점에 안정성을 확보해야 하는 경우(릴리즈 브랜치 유용) | 지속적 통합·배포(CI/CD)에 적합빠른 배포와 간결한 브랜치 전략 |
개발을 하며 겪었던 문제들을 경험으로 삼고 Git branch 전략을 도입해서
이제는 보다 안정적이고 효율적인 개발 환경을 구축해 보려고 한다!