🐝 브랜치 전략
여러 개발자가 하나의 저장소를 사용하는 환경에서 해당 저장소를 효과적으로 활용하기 위한 work-flow(작업 흐름)
- 참조 블로그
아래는 깃 플로우를 검색하면 나오는 가장 대표적인 이미지입니다.
깃 플로우에는 5가지의 브랜치 종류가 존재하며 개발의 목적에 따라 사용하게 됩니다.
- main(master): 실제로 제품이 출시되는 주 브랜치
- develop: 다음에 출시할 버전을 개발하는 주 브랜치
- feature: 추가적인 기능을 개발하는 보조 브랜치, develop 브랜치에 포함됨
- release: 이번에 출시할 버전을 준비하는 보조 브랜치, develop 브랜치에서 개발한 내용을 해당 브랜치로 옮겨와 QA 및 테스트를 진행함
- hotfix: 출시된 버전(main 브랜치)에서 발생한 버그를 수정하는 보조 브랜치
🐝 주 브랜치
주 브랜치는 항상 유지되는 브랜치로, main과 develop 브랜치가 존재합니다.
main 브랜치는 실제로 운영되고 있는 서비스입니다.
항상 안정적으로 배포가 가능한 상태의 코드만을 관리합니다.
따라서 해당 브랜치에 검증되지 않은 브랜치를 병합하는 경우 큰일이 일어날 수도 있습니다.
develop 브랜치는 다음에 배포할 내용을 개발하는 브랜치입니다.
평소에는 해당 브랜치를 기반으로 개발을 진행하게 되며, 개발이 완료되면 main 브랜치에 병합됩니다.
🐝 보조 브랜치
보조 브랜치는 필요에 따라 생겨났다가 없어지며, feature와 release, 그리고 hotfix 브랜치가 존재합니다.
feature 브랜치는 develop 브랜치를 기반으로 분기되어 새로운 기능을 개발할 때 사용하는 브랜치입니다.
해당 브랜치에서 자유롭게 개발한 뒤, 개발이 완료되면 다시 develop 브랜치에 병합합니다.
보통 개발자의 개인 저장소에만 존재하기 때문에 원격 저장소(origin)에는 push하지 않습니다.
release 브랜치는 develop 브랜치를 기반으로 분기되어 이미 개발된 기능을 점검할 때 사용하는 브랜치입니다.
해당 브랜치에서 버그가 발견되면 이를 수정하고, develop 브랜치에도 동일하게 적용시켜 주어야 합니다.
점검을 마친 후에 배포 가능한 상태가 되면, main 브랜치에 바로 병합하거나 develop 브랜치에 병합합니다.
hotfix 브랜치는 배포가 완료된 버전에서 급하게 고쳐야 할 사항을 수정하기 위해 사용하는 브랜치입니다.
배포가 완료된 버전에서의 수정 사항이므로 main 브랜치에서 분기되어 나옵니다.
수정을 완료한 내용은 develop 브랜치에도 동일하게 적용시켜 주어야 합니다.
수정을 마친 후에 배포 가능한 상태가 되면, main 브랜치에 바로 병합하거나 develop 브랜치에 병합합니다.
보통 hotfix 브랜치는 긴급하게 버그를 수정할 때 사용되는 브랜치이므로 과정이 완료되면 해당 브랜치를 삭제해줍니다.
🐝 개발 흐름 예시
깃 플로우가 실제 개발에 적용되는 예시입니다.
- 새로운 기능을 개발하기 위해 개발자는 기존의 develop 브랜치에서 새로운 feature 브랜치를 생성하여 작업을 시작
- feature 브랜치에서의 작업이 완료되면 다시 기존의 develop 브랜치로 병합(보통 pull request로 코드 리뷰를 받은 뒤에 병합)
- 다음에 출시할 버전을 준비하기 위해 기존의 develop 브랜치에서 새로운 release 브랜치를 생성하여 코드를 점검
- 충분한 테스트를 거친 후에 main 브랜치로 병합하여 제품을 출시
- 배포한 제품에서 버그가 발견되었다면 hotfix 브랜치를 생성하여 수정
깃 플로우 전략 외에도 깃허브 플로우 전략이 존재합니다.
읽어주셔서 감사합니다:)
