branch 전략 (git flow & github flow)

 

 

git flow

---

 

Master

제품 출시 버전을 관리하는 브랜치. 항상 안정적인 상태를 유지해야 함

어떤 기능 개발을 하고 있더라도 마스터는 항상 실제 서비스로 언제든지 나갈 수 있는 상태로 유지되어야 한다.

 

Develop

최초의 마스터로부터 파생이 되어 나가서 개발중인 feature브랜치들 기능들이 통합되는 개발용 브랜치

개발 중인 기능들이 통합되는 브랜치. 다음 릴리스(버전)를 준비하는 개발 작업이 이루어짐

 

Feature

새로운 기능 개발을 위해 develop 브랜치에서 파생된 브랜치. 개발이 완료되면 develop 브랜치에 머지

 

Release

다음 릴리스(버전)를 준비하는 단계에서, 최종 수정 및 버그 수정을 위해 develop 브랜치에서 파생되는 브랜치 (일종의 스냅샷)

 

Hotfix

긴급한 버그 수정을 위해 master 브랜치에서 파생, 수정 후 master와 develop 브랜치에 머지

develop에서는 새로운 기능들이 개발이 되고 있어서 안정적이다 라고는 볼 수 없다. 그래서 실제로 운영중인 격리된 master 시점에서 버그를 해결하고 버그가 해결되면 다시 master에 그 기능을 머지를 해서 버그가 해소된 신규 버전으로 배포를 하고 그 수정사항 자체도 develop에 다시 붙여줌으로써 develop 브랜치에서도 해결된 이슈를 반영을 함

 

git flow의 장점

안정성을 가장 많이 보장할 수 있다. master같은 경우 개발 브랜치가 develop 기준으로 동작을 하기 때문에 개발중에 어떠한 이슈가 발생을 하더라도 실제로 사용자에게 서비스가 되고 있는 부분에 대해서는 항상 안정적인 상태를 유지.

Release 주기를 체계적으로 관리할 수 있다. feature같은 경우 develop으로부터 파생이 되기 때문에 영향없이 동시에 개발을 하고 각자 테스트를 한다든지 행동을 취할 수 있다. 

단점 : 복잡성 자체로 문제. master가 안정적으로 운영이 된다는 부분은 새로운 기능이 실제로 배포가 될때까지(즉, 마스터에 도달하기까지) 굉장히 많은 과정과 리소스가 필요해진다라는 말. 긴밀하게, 빠르게 다양한 기능들을 실험해야 하는 조직에서는 무거운 방법론이 될 수 있다. 

 

 

 

 

 

 

 

 

 

github flow

---

 

 

Master

제품 출시 버전을 관리하는 브랜치. 항상 안정적인 상태를 유지해야 함

 

Feature

새로운 기능 개발을 위해 master 브랜치에서 파생된 브랜치. 개발이 완료되면 master 브랜치에 머지 (좀 더 엄격한 관리를 요함)

 

github flow란?

git flow에 비해 조금은 간단함. master 브랜치와 각 feature 브랜치들로만 구성됨. 

feature가 master로부터 뻗어나오고 다시 master로 합쳐지는 구조. 

master로 머지가 되면 그게 실제로 배포되는 버전과 동일하다. = feature브랜치가 master에 머지가 되는 순간 배포가 됨.  

Pull request 과정에서 엄격한 코드리뷰와 테스트를 권장한다.

단점 : 대규모 서비스, 프로젝트에서는 master에서 모든것이 관리된다는게 안정성이 떨어지는 측면이 있다. git flow 같은 경우 master로부터 안정적인 상태가 항상 유지되고 있기 때문에 문제가 생겼을때 그 시점에 가서 다시 버전을 배포하면 위기 대응이 훨씬 빠르게 진행이 되지만,

github flow 같은 경우 master로 배포한 것들이 바로 서비스에 배포가 되기 때문에 Hotfix에 불리하다. 또한 Hotfix를 하더라도 새로운 실수가 발생할 수 있는 위험성을 지니고 있다.