Git은 브랜치로 작업을 관리한다.
팀에서 브랜치를 어떻게 사용할 지에 대한 규칙을 Workflow 라고 한다. Git을 사용한 가장 대표적인 Workflow는 Git flow, Github flow, Gitlab flow가 있다.
브랜치의 역할이 명확하고 대규모 프로젝트에 적합하다.
5개의 브랜치로 관리하며 2개의 메인 브랜치인 master, develop와 3개의 보조 브랜치인 feature, release, hotfix로 나뉜다.
출처 : https://techblog.woowahan.com/2553/
master
제품으로 출시하는 브랜치
실제 배포 중인 상용 버전
develop
다음 출시 버전을 개발하는 브랜치
실제 작동 중인 버전의 다음 버전을 개발하기 위한 메인 스트림
feature
기능을 개발하는 브랜치
develop 브랜치에서 뻗어 나와 다시 develop 브랜치로 합쳐진다.
실제 개발을 할 때 가장 많이 사용하는 브랜치이다.
일반적으로 기능별 브랜치를 생성하고 기능 개발을 마치면 develop에 병합한다.
일반적으로 브랜치 명은 자유롭게 사용하며, origin에 Commit 하지 않고 local에서만 작업한다.
release
새로운 버전을 배포하기 위한 브랜치, QA의 용도
develop에서 뻗어 나와 다시 develop으로 합쳐지거나 배포 준비가 끝났으면 master로 합쳐진다.
주로 버그를 수정하는 디버깅만 커밋한다.
release-* 라는 이름을 사용한다.
master에 병합했다면 develop에도 병합해서 변경된 내용을 일치시킨다.
hotfix
상용 제품에서 버그가 발생했을 때 처리하는 브랜치
master 브랜치에서 뻗어나와 master와 develop에 합쳐진다.
버그 픽스를 위한 브랜치로 디버깅만 커밋하며, 보통 일회성으로만 사용한다.
버그를 수정하면 master와 develop에 모두 merge시킨다.
작업 과정
하나의 메인 브랜치인 master 브랜치를 중점으로 운용하며 pull requset를 활용하는 방식
master 브랜치는 항상 최신 버전을 유지하며 안정적이어야 한다.
출처 : https://onwah.tistory.com/12
github flow는 브랜치의 용도가 명확하게 분류되지 않기 때문에 브랜치를 생성 할 때 어떤 작업을 위한 브랜치 인지 명확하게 작성해야 한다.
일반적으로 feature 브랜치의 작업은 local 저장소가 아닌 원격 저장소에 저장한다.
작업 과정
1. 개인 작업은 feature 브랜치에서 작업하며 작업이 끝나면 pull request를 생성한다.
2. pull request에서 코드 리뷰 후에 문제가 없으면 master로 병합한다.
3. master에 병합하면 바로 배포 작업을 수행한다. (CI 자동화 권장)
master와 develop 2개의 메인 브랜치로 관리한다. (master, production으로 분류하기도 함)
항상 최신 버전의 버전을 유지하지 않아도 되며 배포 버전과 개발 버전을 따로 둘 수 있다는 장점이 있다.
출처 : https://www.programmersought.com/article/67295063384/
develop 브랜치는 github flow의 develop브랜치와 같은 역할을 한다. (항상 최신 버전의 코드를 관리하며 작업을 하는 메인 브랜치)
master 브랜치는 배포 버전이다.
작업 과정
1. 개인 개발은 feature 브랜치에서 작업하고 개발이 완료되면 develop 브랜치로 merge한다.
2. develop 브랜치가 배포되기 적합하다고 판단되면 master브랜치로 merge한다.
https://techblog.woowahan.com/2553/
https://onwah.tistory.com/12
https://www.programmersought.com/article/67295063384/