![[Git] Git Branch 전략 || Github Flow vs. Git Flow vs. GitLab Flow](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbiCdqk%2FbtrGx34aQhu%2FKHoVDAHrVvNZwKzkbco67K%2Fimg.png)
❕ Branch
가지를 뻗어나가듯이, 다른 작업(브랜치)의 영향을 받지 않고 독립적으로 작업을 진행할 수 있는 공간이다.
“독립적”이라는 특징을 가지고 있기 때문에 기능 구현 & 오류 수정 등 다양한 작업이 동시에 진행될 수 있다.
( master/main 브랜치 : 기본 브랜치 )
❕ Branch 전략
여러 명의 개발자가 하나의 저장소를 가지고 협업하는 환경에서, 효율적으로 관리하기 위해 각 브랜치에 대한 역할을 설정하고, 규칙을 정하는 것 등을 의미한다.
- 어느 브랜치가 가장 최신인가
- 어디서부터 끌어와서 개발을 시작해야 하는가
- 어디로 push해야하는가
등등의 상황을 줄이고자 사용된다.
📌Github Flow
Github Flow는 Git Flow의 브랜치 전략이 매우 복잡하고 적용하기 힘들기 때문에 생기게 된 브랜치 전략이다.
중심에는 master 브랜치, 기능 추가 및 오류 수정 등의 단위 작업을 위한 브랜치들이 생기고 merge되는 형태이다. 따라서, master에 대한 규칙만 정확하게 정립되는 편이다.
- master 브랜치를 base 지점으로 새로운 브랜치를 생성하고 단위 작업을 진행한다.
- merge를 하기 전, Pull Request를 생성한다.
- PR(Pull Request)에 대해 검토하고 토의한 후 승인한다.
- 테스트를 진행한 후 merge한다.
PR에 대해 제대로 테스트가 진행되어야, 배포가 가능하고 제일 안정적인 master 브랜치에서의 오류를 방지할 수 있다.
🔽 RULE
- master 브랜치는 항상 최신 상태를 유지하고 배포가 가능해야 한다
- 브랜치는 항상 master 브랜치로부터 생성하기 & 의도를 명확히 나타낼 이름으로 작성하기
- 수시로 push하여 어떤 작업을 하는지 다른 사람에게 알리기
- PR을 통해 토의하고 테스트 후 merge한다.
- merge된 후 즉시 배포되어야 한다. (CI/CD)
❔Pull Request
내가 수정한 코드를 검토 후에 병합해달라는 요청
바로 병합되지 않기 때문에 코드 충돌을 줄이고, 코드 리뷰에 용이하다.
❔CI/CD
CI(Continuous Integration), 지속적인 통합은 소스코드의 변경 사항이 정기적으로 빌드 및 테스트되어 원격 저장소에 통합되는 것을 의미한다. “빌드/테스트 자동화 과정”으로 여러 개발자의 코드 충돌을 해결할 수 있고, 신속하고 빠르게 코드를 검증하며 오류 발견과 릴리즈 시간을 단축할 수 있다.
CD(Continuous Delivery & Deployment), 지속적인 서비스 제공 또는 배포는 성공적으로 병합된 것을 이용하여, 사용자가 사용할 수 있는 환경까지 릴리즈되는 것을 의미한다. “배포 자동화 과정”으로사용자에게 빠르게 최신 버전을 제공할 수 있다.
❕ 장단점
✅ 장점
- 단순한 방식으로 git이 익숙하지 않은 사람도 쉽게 적용할 수 있다.
- PR을 통해 코드 리뷰가 자연스럽게 이루어진다.
- CI/CD로 빠른 검증과 배포가 진행된다.
✅ 단점
- CI/CD가 자동화되어 있지 않은 경우, 수동으로 진행해야 한다.
- 단순한 만큼 규칙도 단순하여, 규모가 커질 경우 어려움이 발생할 수 있다.
📌Git Flow
🔴 메인 브랜치 : 항상 유지된다.
🟡 보조 브랜치 : master 브랜치에 병합되면 지우는 편이며, 필요할 때에만 유지된다.
🔴 master
최종적으로 배포(출시)가 이루어지는 중심이 되는 브랜치
🔴 develop
다음 버전 출시를 대비하여 개발이 진행되는 브랜치
🟡 feature or topic
단위별 기능 구현을 담당하는 브랜치
🟡 release
다음 버전 출시를 준비하는 브랜치
🟡 hotfix
배포된 상황에서 버그가 발생했을 경우, 수정을 위한 브랜치
❕ 기능 개발
- master 브랜치에서 develop 브랜치 생성
- develop 브랜치로부터 기능 개발을 위한 feature 브랜치 생성
- feature 브랜치에서 단위 기능 개발 후, develop 브랜치로 merge
❕ 배포
- 기능 구현이 다 된 feature 브랜치가 develop 브랜치로 merge된 후
- QA(Quality Assurance, 품질 보증) 및 테스트를 위해 release 브랜치 생성
- 검수 작업이 모두 통과되면, master 브랜치 & develop 브랜치로 merge
❕ 배포 후 관리
- 배포가 이미 되었는데 버그가 발생한 경우, hotfix 브랜치 생성
- 수정 후 master 브랜치 & develop 브랜치 merge
❕ 장단점
✅ 장점
- 대부분의 에디터 및 IDE에 플러그인으로 존재한다.
✅ 단점
- Branch가 뻗어나가는 것이 복잡하여 관리에 어려움이 있다.
- 복잡한 규칙을 설정해둔다고 해서 버전 관리가 안정적인 것은 아니다.
- 사용에 따라 불필요한 브랜치가 생긴다.
📌Gitlab Flow
Github Flow는 너무 단순하고, Git Flow는 복잡하다고 하니, 좀 더 효율적인 브랜치 전략으로 Gitlab Branch가 있다.
❕ master
Git Flow의 develop 브랜치처럼, feature 브랜치가 master 브랜치로부터 생성되고 병합된다.
테스트 진행 후, production 브랜치로 merge
❕ feature
기능 구현이 이루어지는 브랜치
master 브랜치로 병합하기 전, Merge Request(=PR)를 생성하여 토의 후 merge한다.
❕ production
Git Flow의 master 브랜치처럼, 배포가 가능한 브랜치
+) pre-production
master → production 사이에 두는 브랜치로, 바로 배포하지 않고 테스트를 진행하는 브랜치
master → production으로 바로 배포가 진행되지 않고 pre-production을 거쳐서 테스트 서버로 배포한 다음, 시간을 두고 반영하는 형태이다.
⇒ production이 항상 최신 상태를 유지할 필요가 없어진다.
❕ 장단점
✅ 장점
- 배포 시기를 지정할 수 없는 경우에 적합하다.
- production 브랜치가 항상 최신 상태를 유지해야할 필요가 없다.
✅ 단점
- 단순하지도 않고 체계적으로 구조화되어 있는 것도 아니라는 점
참고)
https://inpa.tistory.com/entry/GIT-⚡️-github-flow-git-flow-📈-브랜치-전략#-브랜치를-계속-나누는-이유
https://chanyeong.com/blog/post/15
https://velog.io/@kw2577/Git-branch-전략