[Git] 09. git branch 방법론

Zero·2023년 2월 9일

git

Git

목록 보기

10/11

서론

개발자 10명이서 브랜치를 대충 아무렇게나 만들면 개발과정이 매우 복잡해지고 추적도 어려워서

git branch 깔끔하게 만들도록 도와주는 방법론같은게 있습니다.

git flow, github flow, gitlab flow, trunk-based 등 다양한 것들이 있습니다.

이런걸 적용하면

브랜치관리가 쉬워지고
팀원이 아무리 많아도 개발절차가 매끄러워집니다.

1. git flow 전략 (안정적인 운영)

만드는 프로그램이 항상 안정적인 release를 해야한다면 (예를 들면 게임개발)

git flow 전략을 쓰면 됩니다.

git flow 전략은 크게 5개 브랜치를 운영하는데

main 브랜치
develop 브랜치 (개발용)
feature 브랜치 (develop에 기능추가용)
hotfix 브랜치 (main 브랜치 버그해결용)
가끔 release 브랜치 (develop 브랜치를 main 브랜치에 합치기 전에 최종 테스트용)

를 운영합니다.

게임개발을 예시로 들어봅시다.

본인이 게임개발 팀장이라고 가정해봅시다.

지금까지는 대충 협업해서 0.9버전까지 만들어놨다고 칩시다.

근데 1.0 버전부터는 신기능도 많고 해서 제대로 개발을 진행하고 싶은겁니다.

그래서 이번엔 git flow를 도입해서 개발을 진행해봅시다.

1. develop 브랜치부터 생성합니다.

신기능 개발해서 바로 main브랜치 합치는 것은 피하는 게 좋습니다.

일단 실험용 프로젝트 사본을 만들고 거기다가 먼저 개발해봅시다.

그러기 위해 main 브랜치에 있던 기존 프로젝트를 복사한 develop 브랜치를 생성합니다.

이제 모든 개발은 develop 브랜치에서 진행하라고 팀원들에게 전파합니다.

2. 신기능개발은 feature 브랜치에서 진행

신기능을 만들고 싶으면 develop 브랜치를 복사한 feature 브랜치에서 각각 개발합니다.

feature/guild 브랜치 만들어서 길드기능 만들고

feature/friend 브랜치 만들어서 친구기능 만들고 하면 됩니다.

(브랜치 작명할 때 여러 단어가 필요하면 보통 대시나 / 기호 씁니다)

완성되면 develop 브랜치에 merge 합니다.
중요한 내용이 아니면 squash and merge도 괜찮습니다.

3. 신버전 출시 준비는 release 브랜치

develop에서 만든 2개 기능들이 완성된 것 같습니다.

이걸 바로 main 브랜치에 합치기엔 또 불안하기 때문에

develop -> release 브랜치 이렇게 프로젝트를 복사한 다음 출시준비를 합니다.

여기서 테스트나 QA같은거 진행하면 됩니다.
버그를 발견하면 알아서 임시 브랜치 만들어서 수정하거나 합니다.
release/1.0 이런 식으로 이쁘게 브랜치 이름을 짓는 경우가 많습니다.

완성된 것 같으면 main 브랜치로 merge 합니다. 그리고 그거 유저들에게 배포하면 됩니다.

개발은 계속 진행되어야하니 완성본은 develop 브랜치에도 merge 해줍시다.

4. hotfix 브랜치

1.0 버전에서 갑자기 골드 무한복사 버그를 발견했습니다.

그런 급한 것들은 main 브랜치에서 hotfix 이런 브랜치 하나 만들어서 바로바로 버그수정하면 됩니다.

수정이 완료되면 main 브랜치에 직접 merge 하면 됩니다.
당연히 develop 브랜치에도 merge 해줘야합니다.

이제 유저들에겐 "잡다한 버그 수정" 공지만 올리고 점검보상 쪼금 주면 됩니다.

게임 뿐만 아니라 웹이나 앱도 비슷하게 운영할 수 있습니다.

2) Trunk-based 전략

코드짠걸 바로 대중에 배포를 해도 상관없는 프로그램이면 그리고 크게 대격변 업데이트를 안하는 안정적인 프로그램이면 굳이 많은 브랜치를 만들 필요가 없습니다. 그냥 main 브랜치와 기능추가용 feature 브랜치만 운영하면 됩니다. 이게 trunk-based 전략입니다. github flow도 이거랑 비슷합니다.