(사진 출처: https://www.youtube.com/watch?v=w2r0oLFtXAw)
git flow 는 총 5 종류의 브랜치를 활용한다.
주의할 점은 master
, develop
은 각 브랜치가 영구적으로 존재하지만, hotfix
, release
, feature
브랜치의 경우 필요할 때마다 브랜치를 만들고, 머지가 되면 삭제된다.
전체적인 merge 순서는 다음과 같다. (merge 할 때는 항상 —-no-ff
옵션을 붙안다.)
feature
→ develop
→ release
→ master
master 브랜치 (main 브랜치)
소비자가 사용하는 제품이 존재하는 (배포될 코드가 있는) 브랜치이다.
release 브랜치로부터 pull request 받는다.
hotfix
, develop
release
hotfix 브랜치
배포된 서비스에 대한 긴급 버그 수정을 진행하는 브랜치이다.
hotfix 브랜치는 만들 때 hotfix-* (hotfix-1)
과 같은 형태로 이름을 지정해서 만든다.
수정이 완료되면, develop 과 master 브랜치 각각에 pr 을 날린다.
master
develop
, master
release 브랜치
배포 전에 제품을 테스트 (QA, 품질검사) 하는 브랜치이다.
release 브랜치는 만들 때 release-* (release-1)
과 같은 형태로 이름을 지정해서 만든다.
테스트가 정상적으로 완료되면, develop 과 master 브랜치 각각에 pr 을 날립니다. pr merge 가 완료되면, 브랜치를 삭제한다.
develop
develop
, master
develop 브랜치
개발 단계의 코드가 있는 (개발의 중심) 브랜치이다.
개발 자체는 feature 브랜치에서 진행하고, 기능 하나 구현이 완료되면 develop 브랜치로 pr 을 날린다.
이러한 과정을 반복하면서 특정 단계까지 개발이 완료되면, develop 브랜치를 베이스로 해서 테스트를 위한 release 브랜치를 새롭게 만든다.
master
feature
, release
feature
feature 브랜치
특정한 기능 (단위 기능) 을 구현하는 브랜치이다.
feature 브랜치는 만들 때 feature/* (feature/기능명)
과 같은 형태로 이름을 지정해서 만든다.
기능 구현이 완료되면, develop 브랜치로 pr 을 날립니다. merge 되면 브랜치는 삭제된다.
develop
develop
Git Flow
는 다음과 같은 경우에 유용하다.
- 큰 규모의 팀
- 퀄리티 보장이 중요한 프로덕트
- release 된 프로덕트에 대한 관리 사이클이 긴 경우
(사진 출처: https://www.youtube.com/watch?v=w2r0oLFtXAw)
Github Flow
는 딱 2가지 종류의 브랜치만 사용한다.
Git Flow
는 큰 규모의 팀 + 안정성이 매우 중요한 서비스에서 사용하면 좋지만, 작은 규모의 팀 + 빠른 개발과 업데이트가 중요한 서비스에서는 오히려 비효율적으로 작용한다.
그렇기 때문에 Github Flow 는 단 2개의 브랜치만을 사용하며, 배포용 브랜치인 master, 각 단위 기능 구현을 위한 브랜치인 feature 로 구성된다. feature 브랜치는 merge 후에 삭제된다.
master 브랜치 (main 브랜치)
소비자가 사용하는 제품이 존재하는 (배포될 코드가 있는) 브랜치이다.
(해당 브랜치는 push 를 받으면 자동으로 실제 서비스로 배포되도록 설정되어있있다.)
feature 브랜치에서 단위 기능 구현이 완료될 때마다 pull request 를 받는다. (여기서 해당 브랜치를 merge 하기 전에 테스트를 진행한다.)
feature
feature
feature 브랜치
특정한 기능 (단위 기능) 을 구현하는 브랜치이다.
feature 브랜치는 만들 때 git flow 보다 더 구체적으로, 명확하게 작업명을 작성해서 만든다.
(단순히 feature/* 가 아니라 버그 해결인지, 기능 추가인지 등을 명확히 명시한다.)
기능 구현이 완료되면, master 브랜치로 pr 을 날린다.
merge 되면 브랜치는 삭제된다.
master
master
Github Flow
는 다음과 같은 경우에 유용하다.
- 작은 규모의 팀
- release 된 프로덕트에 대한 관리 사이클이 짧은 경우 (업데이트 주기가 짧은 경우)
- 빠른 배포와 관리가 필요한 경우
(사진 출처: https://www.youtube.com/watch?v=w2r0oLFtXAw)
Gitlab Flow
는 4종류의 브랜치를 사용한다.
github flow 는 테스트를 위한 브랜치가 없고, 배포용 브랜치가 따로 없기 때문에 큰 규모의 서비스에는 적합하지 않다. 그래서 github flow 의 단순함과 git flow 의 체계적인 관리를 합쳐서 절충적으로 git 을 활용하는 방식이 바로 gitlab flow 이다.
pre-production 브랜치가 테스트를 담당하고, master 브랜치가 개발용 브랜치로 역할한다.
feature 브랜치는 다른 flow 와 마찬가지로 merge 되면 삭제됩니다.
production 브랜치
소비자가 사용하는 제품이 존재하는 (배포될 코드가 있는) 브랜치이다.
pre-production 브랜치로부터 pull request 받는다.
master
pre-production
pre-production 브랜치
배포 전에 제품을 테스트 (QA, 품질검사) 하는 브랜치이다.
테스트가 정상적으로 완료되면, production
과 master
에 각각 pr 을 날린다.
master
master
production
, master
master 브랜치 (main 브랜치)
개발 단계의 코드가 있는 (개발의 중심) 브랜치이다.
개발 자체는 feature 브랜치에서 진행하고, 기능 하나 구현이 완료되면 master 브랜치가 pr 을 받는다.
이러한 과정을 반복하면서 특정 단계까지 개발이 완료되면, pre-production 으로 pr 을 날린다.
feature
feature
, pre-production
pre-production
feature 브랜치
특정한 기능 (단위 기능) 을 구현하는 브랜치이다.
브랜치명은 github flow 처럼 자세하게 작성한다.
기능 구현이 완료되면, master 브랜치로 pr 을 날린다.
merge 되면 브랜치는 삭제된다.
master
master
Gitlab Flow
는 다음과 같은 경우에 유용하다.
- 중간 규모의 팀
- 퀄리티 보장이 중요한 프로덕트
- 빠른 배포와 관리가 필요한 경우
소중한 정보 잘 봤습니다!