성공적인 Git 브랜칭 모델

김유상·2022년 12월 22일
0

  • 메인 브랜치(Main branch)

    일반적으로 master와 develop을 메인 브랜치로 사용한다.
    master: 배포 가능한 상태만을 관리한다. 커밋할 대에는 태그를 이용해 배포 번호를 기록한다.
    develop: 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행한다.

  • 피처 브랜치(Feature branch) 또는 토픽 브랜치(Topic branch)

    새로운 기능 개발 및 버그 수정이 필요할 때에 'develop'브랜치로부터 분기하면서 만들어진다. 피처 브랜치의 작업은 보통 공유할 필요가 없기 때문에, 원격으로 관리하지 않는다. 개발이 완료되면 'develop'브랜치로 병합해서 공유한다.

  • 릴리스 브랜치(Release branch)

    버그를 수정하거나 새로운 긴으을 포함한 상태로 모든 기능이 정상적으로 동작하는지 확인한다. 관례적으로 브랜치 이름 앞에 'release-'를 붙인다. 이때, 다음 번 릴리즈를 위한 개발 작업은 'develop'브랜치에서 계속 진행해 나가면 된다.

    릴리즈를 위한 최종적인 버그 수정 등의 개발을 수행하는데 모든 준비를 마치고 배포 가능한 상태가 되면 'master'브랜치로 병합시켜 릴리즈한다.

    기능 점검 중에 수정 사항이 있었다면 해당 내용을 'develop'브랜치에도 반영해야 한다. 따라서 배포 후 'develop'브랜치에 대해서도 병합 작업을 수행한다.

  • 핫픽스 브랜치(Hotfix branch)

    배포한 버전에 긴급하게 수정을 해야 하는 경우, 'master'브랜치에서 분기하는 브랜치이다. 관례적으로 브랜치 이름 앞에 'hotfix-'를 붙인다.

    갑작스러운 버그가 발생할 때, 지금 당장 'develop'에 사용되는 코드부터 변경해서 배포하기에는 많은 시간이 걸릴 수 있다. 따라서 이러한 경우에는 일단 'master'브랜치에서 직접 브랜치를 만들어 수정 후 배포하고 수정 사항에 대해서는 이후에 'develop'에 반영하는 방법이 유동적이고 좋을 수 있다.

Referenced: https://backlog.com/git-tutorial/kr/stepup/stepup1_5.html

profile
continuous programming

0개의 댓글