우아한테크코스 4기

🥄 Git Flow 한 스푼

리차드 2022. 7. 14. 03:37

 

Git Flow 전략에 대해 알아본 내용을 정리합니다.
각각의 브랜치들이 왜 필요한지,
생애주기는 어떻게 되는지,
다른 브랜치들과 어떻게 상호작용하는지 알아보겠습니다.

 

 

Git Flow

https://nvie.com/posts/a-successful-git-branching-model/

 

 

main 브랜치

생애주기

  • 서비스의 탄생, 종료와 생애주기를 같이하는 브랜치입니다.
  • 계속해서 유지되는 브랜치입니다.

 

필요성

  • 최종적으로 고객에게 전달되는 내용이 관리되는 브랜치입니다.
  • 즉, 운영 환경에 현재 배포되어 있는 내용입니다.

 

특징

  • 시멘틱 버저닝 전략을 활용하여 버전 태깅을 합니다.

 

다른 브랜치와의 상호작용

  • develop : 서비스의 탄생 시점에 한 번 파생
    • 개발된 기능을 병합하는데 사용될 develop 브랜치를 main 브랜치 탄생 시점에 파생시킵니다.
  • hotfixes : 긴급한 장애 대응이 필요할 경우
    • main 브랜치에서 hotfixes 브랜치를 파생시킵니다
    • hotfixes 브랜치에서 장애 대응을 진행한 후, main 브랜치에 병합합니다.
    • hotfixes 브랜치가 main 브랜치에 병합될 경우,
      이 내용을 develop 등의 다른 브랜치에서도 pull 받아야 합니다.
  • releases : 다음 버전 배포
    • releases 브랜치에서 다음 배포 주기에 배포될 내용이 병합됩니다.
    • QA가 완료된 후, releases 브랜치를 main 브랜치에 병합함으로써 새 버전을 배포합니다.
    • releases 브랜치가 main 브랜치에 병합된 후에는
      이 내용을 develop 등의 다른 브랜치에서도 pull 받아야 합니다.

 

 

 

develop 브랜치

생애주기

  • main 브랜치의 탄생 이후 main 브랜치에서 파생되어 생애주기를 시작합니다.
  • 계속해서 유지되는 브랜치입니다.

 

필요성

  • 기능 단위별로 개발된 코드들이 병합되는 브랜치입니다.
  • 개발된 기능의 병합과 운영 배포 시점을 분리하기 위해 필요합니다.
    • 충돌 없이 병합되었다고 해서 즉시 배포 가능한 상태라는 의미는 아닙니다. 
    • 병합된 상태에서 배포 가능한 상태인지 추가적인 테스트를 진행해야 합니다.

 

특징

  • 여러 기능이 동시다발적으로 개발되는 것이 가능하게 해주는 뿌리와 같은 역할을 합니다.
  • 즉, 각각의 기능 개발 브랜치들은 develop에서 파생되어 병합되기 위해 개발됩니다.
  • 만약 개발 -> 검증 -> 운영 서버를 구분하여 운영한다면,
    develop 브랜치가 배포된 개발 서버는 운영 환경과 유사한 상태에서 테스트해보고 롤백해볼 수 있는 환경을 제공해줍니다.

 

다른 브랜치와의 상호작용

  • feature : 신규 기능 개발
    • develop 브랜치에서 feature/개발하고자-하는-기능 브랜치를 파생시킵니다.
    • 개발이 완료된 후 feature 브랜치는 develop 브랜치에 merge 됩니다.
  • hotfixes : 긴급한 장애 대응이 필요할 경우
    • main 브랜치에 hotfixes 브랜치가 병합된 경우,
      develop 에서도 이 내용을 pull 받아야 합니다.
    • 추후 develop -> release -> main 으로 반영될 때, hotfixes 가 반영되어야 하기 때문입니다.
  • releases : 다음 버전 배포
    • feature 브랜치들을 develop 에 병합하며 기능 개발을 진행합니다.
    • 배포 주기가 도래하면, 이번 배포에 어느 기능까지 배포할지 결정해서
      develop 브랜치로부터 releases 브랜치를 파생시킵니다.
    • release 브랜치에서 추가 커밋이 발생할 경우, 이를 develop 에서도 pull 받아야 합니다.

 

 

 

feature 브랜치

생애주기

  • develop 브랜치로부터 파생되어 생애주기를 시작합니다.
    • 보통 feature/개발하고자-하는-기능 와 같은 브랜치명을 지닙니다.
  • 개발이 완료된 이후 develop 브랜치에 merge 하고 feature 브랜치는 제거함으로 생애주기를 마칩니다.

 

필요성

  • 여러 기능이 동시 다발적으로 개발될 수 있게 해주는 브랜치입니다.
  • 하나의 develop에서 파생되어, 동시에 여러 feature 브랜치들이 유지되며 개발될 수 있습니다.

 

특징

  • 하나의 기능 단위마다 개별 feature 브랜치에서 작업을 진행합니다.
  • 따라서 동시에 여러 feature 브랜치가 존재할 수 있습니다.
  • 단, 같은 파일의 같은 행을 여러 feature 브랜치에서 수정할 경우 충돌이 발생합니다.
    • 따라서 develop에 변경이 발생할 때마다 모든 feature 브랜치는 이를 pull 받아야 합니다.

 

다른 브랜치와의 상호작용

  • develop : 기능 개발의 시작점이자 종착점
    • 기능 개발을 시작할 때 develop에서 파생되고,
      개발이 완료된 후 develop에 병합되고 feature 브랜치는 제거됩니다.

 

 

 

release 브랜치

생애주기

  • develop 브랜치로부터 파생되어 생애주기를 시작합니다.
  • main 브랜치에 병합되는 순간이 생애주기를 마치는 순간입니다.

 

필요성

  • 배포 주기가 다가올 때까지 develop 브랜치에 여러 기능들이 개발되고 병합됩니다.
  • 배포 주기가 다가오면 develop 브랜치에서 release 브랜치를 파생시킵니다.
    • develop 에선 지속적으로 개발 시작과 병합이 이뤄지지만
      release 브랜치는 이번 배포 주기에 배포될 기능들이 온전히 유지됩니다.
    • 이때 release 브랜치에 시멘틱 버저닝 태그를 추가합니다.
    • 즉, 이 release 브랜치가 main에 배포되는 순간이 운영 배포이자 버전 업데이트 순간입니다.
  • 운영 배포 전, release 브랜치를 배포하여 운영 환경과 최대한 유사한 환경에서 최종 QA 테스트를 진행합니다.
  • develop 브랜치를 통해 여러 기능이 동시 다발적으로 개발되면서도,
    동시에 배포 주기에 맞춰 QA 테스트와 code freezing 이 가능하게 하는 역할을 수행합니다.

 

특징

  • release 를 준비하는 과정에서 일부 수정이 필요할 경우, release 브랜치에서 직접 작업합니다.
    • develop 브랜치에서는 이미 release 브랜치를 분기시킨 이후
      다른 기능들이 많이 병합된 이후일 수 있기 때문입니다.
    • 단, release 브랜치에서 추가 커밋이 발생한 경우, 
      이 내용을 develop과 feature 브랜치들에 pull하여 반영해야 합니다.
    • 이처럼 release 브랜치에서 변경이 일어날 경우 큰 비용을 치러야 하므로
      이번 버전에서 꼭 수정해서 배포되어야 하는 버그 픽스만 진행하는 것이 좋겠습니다.

 

다른 브랜치와의 상호작용

  • develop : 배포 주기에 맞춰 파생하여 생성. 
    • release 브랜치는 develop 브랜치에서 파생되어 생애주기를 시작합니다.
    • release 브랜치에서 수정이 일어났을 경우, 이를 develop에도 반영해야 합니다.
  • main : 신규 버전 운영 배포
    • release 브랜치를 통해 충분히 검증을 수행하고 시멘틱 버저닝을 적용합니다.
    • main 브랜치에 release 브랜치를 병합시키는 순간이 곧 새 버전 운영 배포 순간입니다.

 

 

 

hotfix 브랜치

생애주기

  • main 브랜치에서 파생되어 생애주기를 시작합니다.
  • 운영 환경에서 발생한 긴급한 오류를 수정하기 위한 작업을 진행합니다.
  • 수정 내용을 main 브랜치에 다시 병합함으로써 생애주기를 마칩니다.

 

필요성

  • 이미 배포되어 있는 운영 환경에서 긴급한 수정이 필요해졌을 때 main 브랜치로부터 생성합니다.
  • develop -> feature -> develop -> release -> main 과 같은 배포 프로세스를 따르기엔
    너무나 시급한 수정이며, 당장 원하는 수정 한 가지만 운영 환경에 반영해야 하기에 적절하지 않습니다.

 

특징

  • hotfix 브랜치에서 필요한 작업을 진행한 뒤, main 과 develop 브랜치에 병합시킵니다.

 

다른 브랜치와의 상호작용

  • main : 수정 대상 브랜치
    • 현재 운영 배포 되어있는 브랜치에 긴급한 수정이 필요할 때 hotfix 브랜치를 main으로부터 파생시킵니다.
    • 수정 작업이 완료되면 main과 develop 에 병합시키고 브랜치를 제거합니다.
  • develop : main과 함께 수정이 반영되어야 하는 브랜치

 

 

 

요약

main은 운영 배포에 사용하는 브랜치입니다.

develop은 main에서 파생되며, 기능 개발 브랜치들이 1차 집결하는 장소입니다.

feature는 하나의 기능 개발 단위마다 생성해서 동시 개발이 진행될 수 있도록 하는 브랜치들입니다.

release는 지속적인 개발과 안정적인 배포를 위해 develop 브랜치와 분리되어 존재합니다. 

hotfix는 긴급한 수정이 필요할 때 main 에서 파생시킨 브랜치로, 
긴급한 수정 반영을 위해 main 브랜치에 병합될 목적으로 생성되는 브랜치입니다.

 

 

저작자표시