Skip to content

브랜치 전략

Sejin Kim edited this page Nov 22, 2019 · 1 revision

브랜치 전략

1. 메인라인 브랜치

완전한 연속 배포

  • 개발자들은 지속해서 하나의 중앙 브랜치에 작업을 커밋한다.
  • 중앙 브랜치는 항상 배포 준비 상태로 유지한다.
  • 자동 빌드 과정을 사용하는 팀들이 하나의 작업 브랜치로 일하는 경우가 많다.
  • 하지만 로컬 저장소에 커밋한 수정사항이 아직 완성된 상태가 아닐 때 마스터 브랜치의 코드와 구분하기 어렵다.

→ 따라서 완전한 연속 배포 전략을 취하지 않고 여러 개의 브랜치와 정기 배포 전략을 사용한다.

정기 배포

장점

  • 코드 베이스에 추가되는 커밋의 양이 상대적으로 적다. → 상대적으로 빠르게 문제가 생긴 부분을 되돌릴 수 있다.
  • 코드가 배포 준비 완료 상태로 메인 브랜치에 저장되기 때문에 긴급 수정의 경우가 드물다.

단점

  • 메인 브랜치에는 배포 준비가 완료된 코드만 올린다는 가정이 깔려, 테스트 기반 시설이 없으면 새로 병합될 코드가 문제 없다고 가정하는 것은 안전성을 보장하지 않는다.

2. 기능별 브랜치 배포

  • 기능 브랜치와 통합 브랜치를 적용한다.
  • 이 두 종류의 브랜치에 어떤 종류의 작업을 커밋할 지 규약을 정해야 한다.
  • 새로운 모든 작업을 기능 브랜치에서 다루고 하나의 온전한 아이이어를 담을 정도만 크기를 정한다.
  • 두개 이상의 기능 브랜치가 병합하기 위해서 통합 브랜치에서 병합을 한 뒤 수정 후, master에 병합한다.
  • 기능을 명시하는 이름의 브랜치를 만들고 작업을 정기적으로 해당 브랜치에 커밋한다.
  • 각 기능 브랜치는 마스터 브랜치의 코드를 가져와 최신 상태를 유지하고 정기적으로 공유 저장소의 브랜치에 push되어 어떤 기능의 작업이 활발한지 다른 사람들이 확인할 수 있도록 한다.
  • 자신의 작업이 완료되거나 도움이 필요하면 마스터 브랜치에 pull request를 보내어 논의가 이뤄진다.
  • Github Flow는 기능 브랜치가 검토 후에 배포되며, 문제가 없으면 마스터에 병합된다.

장점

  • 메인라인 개발처럼 빠른 코드 배포에 초점을 맞춘다.
  • 선택적인 빌드 단계가 있다. → 어떤 기능을 마스터 브랜치에 통합해 배포할 것인지 선택할 수 있다.

단점

  • 코드가 기능 브랜치에 저장된 경우, 바로 마스터에 추가되지 않으면 해당 기능이 배포 브랜치로 추가되기 전까지 개발자들은 추가로 유지 보수 작업을 해 코드를 최신 상태로 유지해야 한다.
  • 마스터에 추가된 오래된 브랜치를 삭제하는 관리 업무를 맡아야 한다.(업무량이 늘어난다)

3. 상태 브랜칭

  • 브랜치 사이에서 실제 코드가 병합되는 방식과 개별 브랜치가 특정 환경에 배포되는 방식을 볼 수 있다.
  • Gitlab Flow 모델: 브랜치 네이밍 규약을 통해 커밋을 병합하기 전에 어떤 코드가 어떤 환경에 사용될 것인지, 또 그에 따라 어떤 조건이 맞아야 하는지 명시한다.
    • 이상적으로 릴리스 브랜치는 의미론적 버전 규약을 따르는 것이 좋다.

변형된 상태 브랜칭 전략 - git 프로젝트의 브랜치

네이밍 규약

  • maint: 가장 최신 안정화 릴리스 버전의 Git 코드와 유지 보수의 추가 커밋을 포함
  • master: 다음 릴리스에 추가될 커밋을 추가
  • next: master 브랜치에 포함되기 전 안정성을 테스트할 코드를 포함
  • pu: 아직 통합될 준비가 완전히 되지 않은 커밋을 포함
  • pu < next < master < maint
  • 더 낮은 브랜치는 더 높은 브랜치에 없는 커밋을 포함한다.

장점

  • 브랜치 이름은 구체적으로 작업 상황을 설명하고 당면 작업과 관련이 있어야 한다.
  • 개별 브랜치의 목적을 추측할 필요가 없어 사람들이 자신의 작업을 병합할 올바른 브랜치를 찾기가 쉽다.

단점

  • 이름을 구체적으로 적는다 해도 안내 없이 어떤 브랜치에서 작업해야 할지 항상 분명한 것은 아님
  • 브랜치 이름이 해당 팀의 상황을 매우 구체적으로 설명하기 때문에 여러 프로젝트 간에 일관성을 유지하기 힘들다.

4. 정기 배포

  • 완전한 테스트 자동화 프로그램들이 없고 정기적으로 배포해야하는 상황에 적절

GitFlow 브랜칭 전략

  • 처음에 하나의 브랜치 develop를 갖는다.
  • 이 브랜치로부터 프로그래머들이 브랜치를 각각 생성하고 기능을 추가한다.
Clone this wiki locally