5. 깃 브랜치 전략

Git 브랜치 전략

여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow

• Git의 유연한 구조를 활용 개발자들의 혼란 감소시키도록 소스코드를 관리
  • 브랜치 생성에 규칙을 만들어 협업을 유연하게 만드는 방법론

브랜치 전략이 없을때?

• 어떤 브랜치가 최신 브랜치지?
• 어떤 브랜치를 끌어와서 개발해야하지?
• 어디에 push를 보내야하지?
• hotfix를 해야하는데 어떤 브랜치를 기준으로 수정하지?
• 배포버전은 어떤걸 고랄야하지?

Git Flow

브랜치 종류

• feature, develop, release, hotfix, master

메인 브랜치

• master, develop
• 항시 유지되는 브랜치

보조 브랜치

• feature, release, hotfix
• 병합시 사라지는 보조 브랜치

GitFlow에서의 브랜치별 역할

master

• 라이브 서버에 제품으로 출시되는 브랜치
• 배포 가능한 상태만을 관리하는 브랜치임.

develop

• 다음 출시 버전을 대비해 개발하는 브랜치
• 즉, 평소엔 해당 브랜치에서 개발함.

feature(develop브랜치에서 뻗어나옴)

• 추가 기능을 개발하는 브랜치
• develop브랜치로 병합됨.

release(develop에서 뻗어나옴)

• 다음 버전 출시를 준비하는 브랜치
• 즉, 배포를 위한 최종 버그 수정을 개발을 수행하는 브랜치
• develop브랜치를 release브랜치로 옮기고 QA, 테스트를 진행하고 master브랜치로 병합
  • 병합시 버전태그를 달고 추가
• 수정 사항은 develop에도 적용함. 따라서 master, develop모두 병합

hotfix(master에서 뻗어나옴)

• master브랜치에서 발생한 버그를 수정하는 브랜치
  • 해당 내용이 master(tag로 기록)와 develop모두에 적용하기 위해 병합한다.
• 1회성 브랜치로 버그 해결시 보통 브랜치를 제거함.

전략 흐름 - 신규 기능 개발

• master브랜치에서 발생한 버그를 수정하는 브랜치
  • 해당 내용이 master(tag로 기록)와 develop모두에 적용하기 위해 병합한다.
• 1회성 브랜치로 버그 해결시 보통 브랜치를 제거함.

전략 흐름 - 신규 기능 개발

1. develop브랜치로부터 신규 개발할 기능을 위한 feature브랜치를 생성
2. 해당 브랜치에서 작업후 develop브랜치로 병합

전략흐름 - 배포

1. feature브랜치가 모두 develop브랜치로 병합된 상태에서 release브랜치를 생성
2. 해당 브랜치에서 오류를 확인하고, 발견할 경우 오류를 수정
3. 테스트 통과 시 master브랜치로 병합 + develop브랜치에도 병합

전락흐름 - 사후 관리

1. 버그가 발생했을 경우 hotfix브랜치를 생성해 디버깅 진행
2. 디버깅 후 develop과 master에 모두 병합해 동기화

---

GitHub Flow전략

흐름

1. 브랜치 생성

체계적인 분류가 없으므로 브랜치 명으로 의도를 드러냄.(새 브랜치 생성 → 뭘 개발할 브랜치임)

• master브랜치는 항상 최신 상태이며, 안정적인 상태로 배포되므로 엄격한 규칙 적용
• 새로운 브랜치는 항상 master브랜치에서 갈라져 나와야함.
  • feature브랜치나 develop브랜치가 없음.
• 기능마다 브랜치를 따서 사용함.

2. 개발 커밋 푸쉬

개발을 진행하면서 커밋을 남김

• 커밋을 최대한 상세하게 적어줘야한다.
• 원격저장소에 수시로 push해줌
  • 다른사람도 확인할 수 있도록 함.
  • 작업 내용이 사라져도 원격 저장소 코드를 받아 작업 가능함

3. PR생성 및 자동화된 테스트

피드백이나 도움이 필요할 때, 병합 준비가 완료되었을 때 pr생성

• 생성시 자동화된 테스트 실행

4. 리뷰 토의

브랜치 쪽에 합쳐지는 것은 라이브 서버 배포이므로 상세한 리뷰 토의가 이루어져야한다.

• 통과 후 코드 리뷰

5. Master로의 병합

코드 리뷰 및 토의 후 master로의 병합 진행

• 자동으로 라이브 서버로 배포됨.

사용처

1개월 이상의 긴 호흡으로 개발하여 주기적으로 배포, 테스트, hotfix등을 수행할 수 있는 여력이 있는 팀이면 gitflow

수시로 배포되어야할 필요가 있는 서비스를 지속적으로 테스트하고 배포하는 팀이라면 github flow(간단)