Git Flow 전략에 대해 알아본 내용을 정리합니다.
각각의 브랜치들이 왜 필요한지,
생애주기는 어떻게 되는지,
다른 브랜치들과 어떻게 상호작용하는지 알아보겠습니다.
https://nvie.com/posts/a-successful-git-branching-model/
main 브랜치
생애주기
- 서비스의 탄생, 종료와 생애주기를 같이하는 브랜치입니다.
- 계속해서 유지되는 브랜치입니다.
필요성
- 최종적으로 고객에게 전달되는 내용이 관리되는 브랜치입니다.
- 즉, 운영 환경에 현재 배포되어 있는 내용입니다.
특징
- 시멘틱 버저닝 전략을 활용하여 버전 태깅을 합니다.
다른 브랜치와의 상호작용
- develop : 서비스의 탄생 시점에 한 번 파생
- 개발된 기능을 병합하는데 사용될 develop 브랜치를 main 브랜치 탄생 시점에 파생시킵니다.
- hotfixes : 긴급한 장애 대응이 필요할 경우
- main 브랜치에서 hotfixes 브랜치를 파생시킵니다
- hotfixes 브랜치에서 장애 대응을 진행한 후, main 브랜치에 병합합니다.
- hotfixes 브랜치가 main 브랜치에 병합될 경우,
이 내용을 develop 등의 다른 브랜치에서도 pull 받아야 합니다.
- releases : 다음 버전 배포
- releases 브랜치에서 다음 배포 주기에 배포될 내용이 병합됩니다.
- QA가 완료된 후, releases 브랜치를 main 브랜치에 병합함으로써 새 버전을 배포합니다.
- releases 브랜치가 main 브랜치에 병합된 후에는
이 내용을 develop 등의 다른 브랜치에서도 pull 받아야 합니다.
develop 브랜치
생애주기
- main 브랜치의 탄생 이후 main 브랜치에서 파생되어 생애주기를 시작합니다.
- 계속해서 유지되는 브랜치입니다.
필요성
- 기능 단위별로 개발된 코드들이 병합되는 브랜치입니다.
- 개발된 기능의 병합과 운영 배포 시점을 분리하기 위해 필요합니다.
- 충돌 없이 병합되었다고 해서 즉시 배포 가능한 상태라는 의미는 아닙니다.
- 병합된 상태에서 배포 가능한 상태인지 추가적인 테스트를 진행해야 합니다.
특징
- 여러 기능이 동시다발적으로 개발되는 것이 가능하게 해주는 뿌리와 같은 역할을 합니다.
- 즉, 각각의 기능 개발 브랜치들은 develop에서 파생되어 병합되기 위해 개발됩니다.
- 만약 개발 -> 검증 -> 운영 서버를 구분하여 운영한다면,
develop 브랜치가 배포된 개발 서버는 운영 환경과 유사한 상태에서 테스트해보고 롤백해볼 수 있는 환경을 제공해줍니다.
다른 브랜치와의 상호작용
- feature : 신규 기능 개발
- develop 브랜치에서 feature/개발하고자-하는-기능 브랜치를 파생시킵니다.
- 개발이 완료된 후 feature 브랜치는 develop 브랜치에 merge 됩니다.
- hotfixes : 긴급한 장애 대응이 필요할 경우
- main 브랜치에 hotfixes 브랜치가 병합된 경우,
develop 에서도 이 내용을 pull 받아야 합니다. - 추후 develop -> release -> main 으로 반영될 때, hotfixes 가 반영되어야 하기 때문입니다.
- main 브랜치에 hotfixes 브랜치가 병합된 경우,
- releases : 다음 버전 배포
- feature 브랜치들을 develop 에 병합하며 기능 개발을 진행합니다.
- 배포 주기가 도래하면, 이번 배포에 어느 기능까지 배포할지 결정해서
develop 브랜치로부터 releases 브랜치를 파생시킵니다. - release 브랜치에서 추가 커밋이 발생할 경우, 이를 develop 에서도 pull 받아야 합니다.
feature 브랜치
생애주기
- develop 브랜치로부터 파생되어 생애주기를 시작합니다.
- 보통 feature/개발하고자-하는-기능 와 같은 브랜치명을 지닙니다.
- 개발이 완료된 이후 develop 브랜치에 merge 하고 feature 브랜치는 제거함으로 생애주기를 마칩니다.
필요성
- 여러 기능이 동시 다발적으로 개발될 수 있게 해주는 브랜치입니다.
- 하나의 develop에서 파생되어, 동시에 여러 feature 브랜치들이 유지되며 개발될 수 있습니다.
특징
- 하나의 기능 단위마다 개별 feature 브랜치에서 작업을 진행합니다.
- 따라서 동시에 여러 feature 브랜치가 존재할 수 있습니다.
- 단, 같은 파일의 같은 행을 여러 feature 브랜치에서 수정할 경우 충돌이 발생합니다.
- 따라서 develop에 변경이 발생할 때마다 모든 feature 브랜치는 이를 pull 받아야 합니다.
다른 브랜치와의 상호작용
- develop : 기능 개발의 시작점이자 종착점
- 기능 개발을 시작할 때 develop에서 파생되고,
개발이 완료된 후 develop에 병합되고 feature 브랜치는 제거됩니다.
- 기능 개발을 시작할 때 develop에서 파생되고,
release 브랜치
생애주기
- develop 브랜치로부터 파생되어 생애주기를 시작합니다.
- main 브랜치에 병합되는 순간이 생애주기를 마치는 순간입니다.
필요성
- 배포 주기가 다가올 때까지 develop 브랜치에 여러 기능들이 개발되고 병합됩니다.
- 배포 주기가 다가오면 develop 브랜치에서 release 브랜치를 파생시킵니다.
- develop 에선 지속적으로 개발 시작과 병합이 이뤄지지만
release 브랜치는 이번 배포 주기에 배포될 기능들이 온전히 유지됩니다. - 이때 release 브랜치에 시멘틱 버저닝 태그를 추가합니다.
- 즉, 이 release 브랜치가 main에 배포되는 순간이 운영 배포이자 버전 업데이트 순간입니다.
- develop 에선 지속적으로 개발 시작과 병합이 이뤄지지만
- 운영 배포 전, release 브랜치를 배포하여 운영 환경과 최대한 유사한 환경에서 최종 QA 테스트를 진행합니다.
- develop 브랜치를 통해 여러 기능이 동시 다발적으로 개발되면서도,
동시에 배포 주기에 맞춰 QA 테스트와 code freezing 이 가능하게 하는 역할을 수행합니다.
특징
- release 를 준비하는 과정에서 일부 수정이 필요할 경우, release 브랜치에서 직접 작업합니다.
- develop 브랜치에서는 이미 release 브랜치를 분기시킨 이후
다른 기능들이 많이 병합된 이후일 수 있기 때문입니다. - 단, release 브랜치에서 추가 커밋이 발생한 경우,
이 내용을 develop과 feature 브랜치들에 pull하여 반영해야 합니다. - 이처럼 release 브랜치에서 변경이 일어날 경우 큰 비용을 치러야 하므로
이번 버전에서 꼭 수정해서 배포되어야 하는 버그 픽스만 진행하는 것이 좋겠습니다.
- develop 브랜치에서는 이미 release 브랜치를 분기시킨 이후
다른 브랜치와의 상호작용
- develop : 배포 주기에 맞춰 파생하여 생성.
- release 브랜치는 develop 브랜치에서 파생되어 생애주기를 시작합니다.
- release 브랜치에서 수정이 일어났을 경우, 이를 develop에도 반영해야 합니다.
- main : 신규 버전 운영 배포
- release 브랜치를 통해 충분히 검증을 수행하고 시멘틱 버저닝을 적용합니다.
- main 브랜치에 release 브랜치를 병합시키는 순간이 곧 새 버전 운영 배포 순간입니다.
hotfix 브랜치
생애주기
- main 브랜치에서 파생되어 생애주기를 시작합니다.
- 운영 환경에서 발생한 긴급한 오류를 수정하기 위한 작업을 진행합니다.
- 수정 내용을 main 브랜치에 다시 병합함으로써 생애주기를 마칩니다.
필요성
- 이미 배포되어 있는 운영 환경에서 긴급한 수정이 필요해졌을 때 main 브랜치로부터 생성합니다.
- develop -> feature -> develop -> release -> main 과 같은 배포 프로세스를 따르기엔
너무나 시급한 수정이며, 당장 원하는 수정 한 가지만 운영 환경에 반영해야 하기에 적절하지 않습니다.
특징
- hotfix 브랜치에서 필요한 작업을 진행한 뒤, main 과 develop 브랜치에 병합시킵니다.
다른 브랜치와의 상호작용
- main : 수정 대상 브랜치
- 현재 운영 배포 되어있는 브랜치에 긴급한 수정이 필요할 때 hotfix 브랜치를 main으로부터 파생시킵니다.
- 수정 작업이 완료되면 main과 develop 에 병합시키고 브랜치를 제거합니다.
- develop : main과 함께 수정이 반영되어야 하는 브랜치
요약
main은 운영 배포에 사용하는 브랜치입니다.
develop은 main에서 파생되며, 기능 개발 브랜치들이 1차 집결하는 장소입니다.
feature는 하나의 기능 개발 단위마다 생성해서 동시 개발이 진행될 수 있도록 하는 브랜치들입니다.
release는 지속적인 개발과 안정적인 배포를 위해 develop 브랜치와 분리되어 존재합니다.
hotfix는 긴급한 수정이 필요할 때 main 에서 파생시킨 브랜치로,
긴급한 수정 반영을 위해 main 브랜치에 병합될 목적으로 생성되는 브랜치입니다.
'우아한테크코스 4기' 카테고리의 다른 글
Sign in with Slack 으로 워크스페이스 내부 구성원 식별하기 (0) | 2022.07.15 |
---|---|
Git Flow 가 CI/CD 와 어울리지 않는 이유 by David Farley (0) | 2022.07.14 |
아이디어 매몰 주의 - (인지적 구두쇠, 기억 편집) (0) | 2022.07.09 |
📖 배민다움을 읽었습니다 (0) | 2022.07.06 |
🧑💻 UX 워크샵 후기 (2) | 2022.07.02 |