Git Flow와 GitHub Flow

Git Flow는 2010년에 Vincent Driessen이 제안한 Git 브랜치 전략으로, 프로젝트의 규모와 복잡성에 따라 다양한 브랜치를 활용하여 개발 프로세스를 관리하는 방법이다. Git Flow는 굉장히 복잡한 형태의 브랜치 관리 전략이지만, 이를 통해서 소프트웨어가 어떻게 개발되는지 한눈에, 그리고 명시적으로 보여 주는 전략이다. main 브랜치와 feature 브랜치만 존재하는 GitHub Flow와는 다르게 Git Flow는 develop / hotfix / release라는 브랜치 개념이 더 있다. 또한 브랜치를 분기하는 방법과 버그를 수정하는 방법도 굉장히 복잡하다. 이러한 복잡성 때문에 간단한 GitHub Flow가 탄생하게 되었고, 많은 사람들이 사용하고 있지만 Git Flow도 하나하나의 개념을 잘 이해한다면, 생각보다 명료하게 이해할 수 있다.

develop & feature 브랜치

GitHub Flow에는 feature 브랜치와 main 브랜치라는 두 가지 개념의 브랜치가 있다.

• main : 항상 배포 가능하도록 준비된 브랜치
• feature : 새로운 기능을 개발하기 위한 브랜치로 새로운 기능을 개발할 때 main 브랜치에서 분기해 개발을 진행하며, 개발이 완료되면 main 브랜치로 다시 머지된다.

Git Flow에서도 GitHub의 main과 feature 같은 기능을 하는 개념의 브랜치가 있다. 기능 자체는 같은 기능을 하지만, 정의 자체는 조금 다르다.

• GitHub Flow의 main 브랜치는 항상 배포 가능함을 보장해야 하지만 Git Flow의 develop 브랜치는 그런 제약 사항이 없다. 물론 모든 기능들이 develop으로 합쳐지기 때문에 최대한 버그가 없이 기능하는 것이 좋겠지만, GitHub flow처럼 항상 배포가능해야 함을 보장하지는 않아도 된다.
• feature 브랜치는 GitHub Flow와 Git Flow가 같은 의미를 가진다. 다만 GitHub Flow는 feature 브랜치가 가능한 짧은 시간 동안만 존재하는 것을 지향하는 반면, Git Flow는 그런 제약 사항이 없다.

이러기 때문에 Git Flow를 사용해 개발할 경우 develop 브랜치와의 코드 버전 이격이 최대한 적게 벌어지도록 develop 브랜치를 자주 머지해 주는 것이 좋다. 특히 feature 브랜치가 장기간 개발될 경우에는 이점을 더욱 신경써야 한다.

그래프에서 보이는 것과 같이 feature 브랜치는 항상 develop 브랜치에서 시작해서 develop 브랜치로 병합된다.

• checkout from: develop
• merge into: develop

release 브랜치

배포 전에는 여러가지를 점검해 보아야 한다. 긴 수명을 가진 feature 브랜치는 main 브랜치로부터 멀어질수록 병합할 때 충돌(conflict)이 발생할 확률이 높아진다. 이러한 충돌을 해결하는 것은 시간이 많이 소요되며, 코드의 품질에도 영향을 줄 수 있다. 또한 지금은 기능이 단 두 가지 뿐이지만, 대규모 프로젝트의 경우 많은 수의 feature들이 동시 다발적으로 개발되게 된다. 때문에 다른 팀원들이 개발한 기능이나 수정 사항과의 호환성 문제가 발생할 수 있다.

이러한 여러가지 이슈들을 해결하는 브랜치가 바로 release 브랜치다. relase 브랜치는 항상 develop 브랜치에서 새로운 분기를 생성한다.

• metadata 수정 : 배포 시에는 다양한 메타 데이터를 프로그램에 삽입해야 한다. 대표적으로 버전 번호, 빌드 날짜, Release Note / Change Log 등이 있다. 이러한 데이터들은 추후 각 버전에서 어떤 기능들이 배포되고, 어떤 문제들이 해결되어 왔는지 코드를 보지 않고도 파악할 수 있게 한다.
• 버그 수정 : 일반적으로 큰 버그들은 develop 브랜치에서 수정되기 마련이다. 하지만 호환성 문제나 예상치 못한 버그들은 직접 테스트를 해보지 않고는 발견하기 어렵다.

release 브랜치를 사용하게 되면, 꼭 우리가 필요로 하는 feature 브랜치들만 병합해서 release 브랜치로 만들 수 있다. release 브랜치를 생성하고 난 이후에는 이번 배포에 포함되지 않은 기능들도 develop 브랜치에 편하게 머지할 수 있다.

모든 메타데이터의 수정과 버그 수정이 완료된 이후에는 main과 develop에 머지한다.
그리고, 해당 버전의 태그를 머지된 커밋에 달게 된다.

• checkout from: develop
• merge into: develop and main

hotfix

feature/f1을 성공적으로 개발하고 난 후, 추가적인 기능을 개발하던 중에 0.0.1버전에서 문제가 발생했다고 가정했을 때 이런 문제를 해결하기 위해 등장한 브랜치가 hotfix 브랜치이다.

hotfix 브랜치는 새로운 프로덕션을 배포하는 것과 마찬가지기 때문에 release 브랜치와 매우 유사하다. 하지만 main 브랜치에서 바로 분기하게 된다. hotfix 브랜치를 사용하는 이유는 프로덕션에서 발생한 버그들은 제품에 치명적인 문제를 야기할 수 있고(비용, 매출, 고객 불편 등), 때문에 빠르게 수정돼야 하기 때문이다.

• develop 브랜치에서 분기 할 경우 이미 다양한 기능들이 추가 됐기 때문에 버그를 찾거나 재현하기 힘들 수 있다.
• develop 브랜치에서 분기 할 경우 검증되지 않은 기능들이 의도치 않게 배포 될 수 있다.

버그가 수정된 이후에는 develop도 같은 문제를 가지고 있을 테니 main과 develop 모두에 머지해준다. 그리고 main에 새로운 버전이라고 명시하며 태그를 달아준다.

• checkout from : main
• merge into: develop and main
  
  
  출처
• 코드잇