Introduce
협업을 한다면 반드시 필요한 git branch 전략에 대해서 알아보려고 한다.
어디가 최신 브랜치인지, 어디에 merge 해야하는지 많이 헷갈린 경험이 있을 것이다.(없을수도 있고)
근본적으로 들어가자면, 올바른 방식으로 협업하기 위한 가장 대표적인 git branch 관리 전략, git-flow와 github-flow 에 대해서 알아보자
git-flow
크게 브랜치 종류가 5 가지로 나뉘어진다.
- develop : 다음 제품 배포 전 개발에 사용하는 개발용 브랜치
- feature : 추가 기능 개발용 브랜치.
- release : 다음 버전 출시를 준비하는 브랜치.
- hotfix :
master브랜치에서 발생한 버그를 수정하는 브랜치 - master : 제품으로서 배포되는 운영용 브랜치
master & develop
main 브랜치는 주로 master 브랜치로 운영되고 실제 배포되는 코드들이 들어 있는 브랜치이다. 그런데 이 master에다가 바로 코드를 밀어넣으면 위험부담이 너무 크다. 그래서 등장한 것이 develop 브랜치이다.
master브랜치랑 똑같이 하나 복사해둔 develop 브랜치를 만들어둔다. 이제 모든 개발한 기능들은 이 develop 브랜치에 밀어넣기로 결정한다.
feature
그런데 기능을 그냥 생짜로 develop브랜치에서 너도나도 모여서 개발을 하게 되면, 매번 fetch해서 변동사항있는지 수시로 확인하고… commit 한번 할 때마다 conflict 한번씩 나주면서… 벌써 화가 머리끝까지 차오르는 기분이다.
그래서 feature브랜치를 활용하면 된다. 예를 들어, develop브랜치에서 새로운 Auth관련 기능을 개발한다고 했을 때, feature/Auth라는 식의 브랜치를 만들어서 위의 그림처럼 독자적으로 개발을 진행하다가, 개발이 끝나면 다시 develop브랜치로 merge하는 방식으로 진행하면 된다.
release
develop브랜치에 개발한 기능들이 들어가서 다 보이게 되었다면 배포 전 QA를 위해 develop브랜치에서 release 브랜치를 생성한다. release/0.1.0 과같은 형식으로 브랜치를 생성하여 사용하면 된다.
QA검증을 마치고 배포 가능한 상태가 되면 master 브랜치로 merge시키고, 뿐만 아니라 develop브랜치에도 수정사항이 반영되어야 하기에 merge해준다.
hotfix
이런, master브랜치에서 서비스되고 있던 제품에 버그가 발생했다. 긴급하게 수정을 해야 되는 상황이 발생했다.
이때, hotfix/0.1.0 브랜치를 생성해 버그를 해결하고, master와 develop에 둘다 반영하면 된다. 긴급하게 수정할 일이 있을 때 master브랜치로부터 사용하는 것이 hotfix브랜치이다.
지금까지 본 이 전략이 git-flow 라는 전략이다.
github-flow
git-flow방식에서 훨씬 단순화된 방법이다.
위의 그림에서 보다시피 기능을 개발할 일이 생겼다. feature브랜치(git-flow 로 따졌을때) 를 만들어 기능을 개발하고, 완료되었을 때 별도의 develop브랜치를 사용하지 않기에 바로 master브랜치로 merge하면 된다.
다만 무슨 브랜치를 생성하여 작업하든 브랜치 이름을 명확하게 해야겠다. 네이밍은 git-flow 방식을 따라가도 괜찮을 것 같다는 생각이다.
git-flow vs github-flow
- 소요가 큰 프로젝트나 기간이 긴 프로젝트에서는 각종 QA, 배포 이런것들이 체계적으로 일어나기 때문에
git-flow방식이 적합하다. - 수시로 release되어야 하고, 지속적으로 변동사항을 서비스중인 제품에 담아야 하는 프로젝트라면
github-flow와 같은 비교적 간단한 workflow가 적합하다.
이 둘의 차이점을 명확하게 알고, 협업할때 야무지게 적용해보자.
