- 브런치 전략을 살펴 볼떄 가장 중요하게 생각되는건 목적 이다
[1]Git Flow
branch 종류를 5가지로 나눈다.
master : 제품으로 출시될 수 있는 브랜치
develop : 다음 출시 버전을 개발하는 브랜치
feature : 기능을 개발하는 브랜치
release : 이번 출시 버전을 준비하는 브랜치
hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
[흐름도]
master와 develop은 항상 유지되는 메인 브랜치들이며 그 외에 feature, release, hotfixes는 필요한 기간에만 유지되는 보조 브랜치들이다.
1.처음 시작은 master — develop
타임라인을 보면 알겠지만 처음에는 master로 시작해 develop브랜치만 존재한다. 아직 소프트웨어를 배포하지 않았기 때문에 develop브랜치에서 개발을 시작한다
2.개발을 진행하다가 추가로 필요한 기능이 생기면 feature브랜치를 생성해 작업을 한다.feature브랜치는 언제나 develop브랜치로부터 시작된다. 기능을 다 개발했다면 작업한 feature브랜치를 검토한 후 develop브랜치에 병합한다.
3.이제 이번 버전에서 필요한 기능이 모두 개발되었다면 QA를 위해 release브랜치를 생성한다.이제 QA과정이 모두 끝났다면 release브랜치를 master와 develop브랜치로 병합한다. 그리고 master브랜치에 버전명시를 위한 태그를 생성 후 배포한다. 여기까지가 기본적인 개발 단계에서의 Git-flow이다.
4.하지만 배포 후에도 버그가 발생하는 경우가 있다. 그렇다면 긴급하게 수정을 해야하는데 그럴 경우 hofixes브랜치를 생성해 발생한 버그를 수정한다.
-> git flow에 대한 문제점 :
테스트 서버의 경우 각자의 feature 브랜치를 테스트하려면 다른 사람의 테스트를 기다려야 하는 문제가 발생합니다.
예를 들어 A와 B가 동시에 개발되고 있는 상황에서 서버 개발자의 로컬 테스트만으로는 충분하지 않은 경우 다른 구성원들도 함께 테스트를 하려면 내부 테스트 서버로의 배포가 필요합니다. 이때 개발 중인 기능은 테스트가 충분히 끝나지 않았기 때문에 develop 브랜치로 merge 할 수 없습니다. 따라서 feature 브랜치 상태에서 테스트 서버에 배포를 해야 하는데 이런 상황에 대한 해결 방안은 git-flow에서는 찾아볼 수 없습니다. A기능에 대한 feature 브랜치를 먼저 배포해서 테스트하고 그 후에 B관련 기능 feature 브랜치를 배포해서 테스트해야 하죠.[1–1]deploy 브랜치 전략
위 문제를 해결하기 위해 당근마켓에서는 deploy 브랜치 전략을 사용해보고 있습니다. 이 전략의 기본은 gitflow와 같지만 추가적으로 테스트 서버 배포를 위한 전용 브랜치를 이용하는 것으로 deploy/{month}라는 브랜치를 이용합니다. month의 경우 한 달의 기간을 의미하는 월을 의미하는데 이는 브랜치 수명을 너무 길게 가져가지 않기 위해 정한 것으로 꼭 이렇게 해야 한다는 것은 아닙니다.
