Git 브랜치 전략
하나의 브랜치에서 여러 개발자들이 동시에 작업을 하고 commit, push 를 한다고 가정해보자. 어떤 일이 벌어질까?
여러 commit 들이 하나의 브랜치에서 뒤죽박죽으로 생성 될 것이고 이에 대한 히스토리는 확인이 어려울 것이다.
실제로 병합된 코드가 사용되지 않기로 하여 롤백되어야 한다면 이 또한 어려울 것이다.
이 외에도 여러가지 문제가 있을 수 있는데 우린 이 문제를 해결하기 위해서 사용할 수 있는 방법이 바로 "브랜치 전략" 이다.
Git-Flow
수 많은 개발자들이 하나의 Repository 아래서 병렬적으로 작업하기 위해서 사용되는 브랜치 전략 중 하나이다.
실제로 실무에서 사용하는 Git-Flow 전략은 회사별로 그대로 사용할 수 도, 조금 더 회사만의 전략을 추가하여 사용 할 수 도 있다.
그래서 Git-Flow 가 뭔데?
Git-flow에 대해 알기 위해서는 꼭 아래 5가지 종류의 브랜치의 역할을 알아야 한다.
항상 존재하고 관리 되어야 하는 master, develop 브랜치.
실제 코드 작업이 시행되고 전략에 따라 움직여야 하는 release, feature, hotfix 브랜치.
master : 최종 브랜치로 제품으로 나가야 되거나 빌드되어야 하는 브랜치
develop : 개발이 완료 되고 다음 제품을 만들기 위해서 시작해야 되는 브랜치.
release : 제품으로 나가야 하기 전 관리되는 브랜치.
hotfix : 제품으로 나가거나, 실제 나가기 직전 버그를 수정하기 위한 브랜치.
feature : 기능을 개발해야 하는 브랜치
위 5가지 브랜치에 대한 상세한 설명을 가장 하위 브랜치 부터 해보자.
"feature" 브랜치
feautre 브랜치는 가장 하위 단위의 브랜치라고 할 수 있다.
실제 우리가 코드를 작성하기 위해서는 feature 브랜치에서 시작한 각자의 작업 브랜치를 생성하여 작업을 한다. (하나의 기능을 혼자 개발한다고 보장 할 수 없기에)
예를 들어 게시판 기능을 개발한다고 한다면 글 작성 기능이 feature 브랜치가 될 수 있다.
"develop" 브랜치
develop 브랜치는 각 기능이 모두 개발된 feature 브랜치를 병합 한 브랜치라고 할 수 있다.
모든 기능이 개발완료된 브랜치로 제품화 되기위해 배포 되어야 하는 브랜치이다.
또한, develop 브랜치는 다음 기능을 개발하기 위한 시작 브랜치가 되어야 한다.
예를 들어 게시판 기능의 모든 기능들 (글 작성, 글 수정, 글 삭제, 댓글 ...)이 병합된 브랜치다.
"release" 브랜치
release 브랜치는 실제 제품화를 위해 배포 되어야 하는 develop 에서 master 로 병합 하기 전 관리를 위한 브랜치이다.
release 브랜치는 develop 브랜치에서 부터 생성되어 지고, 생성된 브랜치는 버전 별로 관리 할 수 있다.
또한, master 로 병합 되기 전 수정해야 하는 버그들이 발견 된다면 수정 할 수 있는 브랜치이다.
주의 할 점은 release 브랜치는 develop 브랜치에서 시작된 브랜치 이기에 release 브랜치에서 버그가 수정으로 인한 코드가 수정 되었 다면 develop 브랜치로 역머지 (release into develop) 꼭 해줘야 한다. *git flow finish
예를 들어 release-1.0(게시판 기능) / release-1.1 (게시판 기능 + 댓글 버그 수정) 이 될 수 있다.
*git flow finish 란 git flow 에서 제공하는 기능으로 자동으로 병합해주는 기능을 말한다.
release 브랜치를 git flow finish 한다면 자동으로 해당 브랜치를 master 와 develop 에 병합해 준다.
"master" 브랜치
master 브랜치는 모든 기능 개발 및 버그 수정이 완료 되어 실제로 제품으로 배포되어야 하는 브랜치이다.
release 브랜치에서 제품으로 나가야 하는 브랜치를 master 브랜치로 병합한다.
master 브랜치에서는 각 회사 별 CI/CD 전략에 따라 배포되어 질 수 있다.
"hotfix" 브랜치
hotfix 브랜치는 있으면 안되는 브랜치이지만.. master 까지 병합 완료된 모든 기능에서 버그를 발견하거나 긴급하게 수정되어야 할 사항이 있다면 master 브랜치에서 시작되어 수정 후 다시 master 로 병합되는 브랜치 이다.
hotfix 브랜치는 수정 후 master 와 develop 에 꼭 반영 되어야 한다. *git flow finish
*git flow finish 를 한다면 release 브랜치와 비슷하게 master 브랜치와 develop 브랜치에 자동으로 병합을 시켜준다.
그림으로 이해해 보자.
위 설명을 쭉 읽어보았다면 아래 그림을 보면 한층 이해가 쉬워 질 것이다.
결론
위 순서를 따라 브랜치 전략을 가져가게 된다면 커밋의 히스토리 및 브랜치 충돌을 예방하고 해결하는데 상당한 도움이 될 것이다.
Git-flow 브랜치 전략에서 더 발전시켜 원하는 장점을 추가한 브랜치 전략 역시 사용할 수 있을 것이다.
