이전 글에서 Git과 Github를 대략적으로 다뤘다면, 이제 실제 프로젝트에서 자주 언급되고 협업에서 필수적인 Git Branch 전략에 대해 알아보자!
1. Branch 원리
여러 개발자가 동일한 파일을 동시에 수정하면 변경사항 통합이 어려워진다. 이를 해결하기 위해 Git에서는 파일을 복사(Branch)하여 각자 별도의 작업 공간을 가질 수 있다. 각 개발자는 자신만의 Branch에서 작업을 진행한 후, 모든 변경 사항을 나중에 하나로 합칠 수 있다.
이 방식은 협업뿐만 아니라, 코드의 일부분을 수정해 실험하거나 테스트할 때도 유용한데, 별도의 Branch를 생성해 작업을 한 후 필요없으면 삭제할 수 있기 때문이다.
2. Branch 병합하기
내 브랜치와 상대방 브랜치를 합칠 때, GitHub에서 PR(Pull Request) 기능을 사용해 병합 전에 PR을 open해서 동료들의 리뷰를 받을 수 있다. 이 과정에서 프로젝트의 규칙에 따라 Approve 절차도 진행할 수 있다.
만약 병합 중 충돌이 발생하면, 로컬에서 충돌을 직접 해결한 후 다시 푸시하는 것을 추천한다!
아래는 내 브랜치와 특정 브랜치를 병합할때 사용하는 명령어이다.
git checkout {branch 이름} : 특정 브랜치로 이동
git pull origin main : 내 로컬 레포지토리로 변경사항 병합
git merge {branch 이름} : 현재 브랜치(main)에 새로운 브렌치 변경사항 병합
git push origin main : 로컬 브랜치의 변경 사항이 원격 저장소에 업로드
3. Git Branch 전략
따라서 팀 내에서 이러한 브랜치를 효율적으로 관리하기 위한 다양한 전략들이 존재한다. 그중에서 대표적인 방식 두가지를 다뤄볼 것이다.
• Git flow
Git Flow는 브랜치를 크게 Main, Develop, Supporting 브랜치로 구분하여 관리한다. Supporting 브랜치는 다시 Feature, Release, Hotfix 브랜치로 세분화된다.
Main 브랜치와 Develop 브랜치는 전체 개발 프로세스에서 항상 유지되는 반면, Supporting 브랜치는 필요할 때 생성되고, 작업이 완료되면 삭제된다. 이 Supporting 브랜치를 통해 팀은 병렬로 작업을 진행할 수 있다.
- master(main) : 서비스 출시가 가능한 Branch
- develop : 다음 버전 개발을 위한 코드를 모아두는 Branch
- feature : 기능을 개발하는 Branch
- release : QA(Quality Assurance)를 진행하기 위해 develop에서 임시로 파생하는 Branch
- hotfix : 서비스 출시 버전에서 발생한 버그를 빠르게 수정하는 Branch
이러한 Git flow에 한계가 존재하는데, 바로 웹 어플리케이션에는 적합하지 않을 수 있다는 것이다!
웹 애플리케이션의 특성상 사용자는 항상 최신의 단일 버전을 사용하게 되므로, 여러 버전을 병렬로 관리할 필요가 없다. 또한, 웹 애플리케이션은 하루에도 여러 번 릴리스를 진행할 수 있기 때문에 복잡한 브랜치 전략이 오히려 비효율적일 수 있다.
• Github flow
Git Flow는 다양한 종류의 브랜치를 사용하는 반면, GitHub Flow는 단일 브랜치 (master)를 사용한다.
Main 브랜치
- 항상 안정적이어야 하며, 모든 커밋은 빌드와 테스트를 통과해야 함.
Topic 브랜치
- 새로운 기능이나 버그 수정을 위해 Main 브랜치에서 생성.
- 기능을 설명하는 명확한 이름으로 네이밍 (예: user-content-cache-key).
- 작업 중이라도 꾸준히 Push하여 데이터 유실 방지 및 팀원과의 지속적인 커뮤니케이션 유지.
PR (Pull Request)
- 기능 개발 중 언제든지 PR을 열어 리뷰와 토론 가능.
- PR에서 코드 리뷰를 받고, 승인(Approve)을 받아야만 Main 브랜치에 병합됨.
- Topic 브랜치는 CI 빌드를 통과해야만 병합 가능.
Github flow는 소규모 애자일 팀과 단일 릴리즈 버전의 제품에 적합하다. 따라서 웹 애플리케이션과 같은 빈번한 배포와 작은 단위 변경에 효과적이다.
4. 약간의 회고(?)
우리팀은 이번 프로젝트에서 Gitflow 전략을 활용해 브랜치를 관리하였다. 다들 처음으로 프로젝트를 진행하는 상황이었기 때문에 가장 많이 사용되는 브랜치 전략을 선택한 것은 좋은 선택이였다고 생각한다.
그러나 프로젝트 초반에 팀원들과 약속했던 PR 날리기나 Comment & Approve 기능을 충분히 활용하지 못한 점이 너무 아쉬웠다..!
다음 프로젝트에서는 꼭 Git과 Github의 기능을 100%로 활용해서 협업을 매끄럽게 진행하고 싶다!
'공부기록 > Git' 카테고리의 다른 글
[Git] Git과 Github (0) | 2024.07.08 |
---|