성공적인 Git branching model 전략

이글은 다음에서 정리한 글입니다.

    http://dogfeet.github.io/articles/2011/a-successful-git-branching-model.html

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

1. develop 브랜치    

    - 갈라져 나온 브랜치        : master

    - 다시 merge할 브랜치    : master, release

    - 다음에 배포할 것을 개발하는 코드는 origin/develop에 두고 관리

    - 코드가 안정되고 배포할 준비가 되면 곧 master로 merge하고 배포 버전으로 태그를 만든다.

        : 이것은 새 버전을 배포하는 것을 의미한다. 

그래서 master 브랜치에 커밋될 때마다 Git hook 스크립트로 자동으로 빌드하고 말아서 운영 서버로 배포할 수 있다.

 2. feature 브랜치    

    - 갈라져 나온 브랜치        : develop

    - 다시 merge할 브랜치    : develop

    - 브랜치 이름 규칙           : feature-[간단한기능설명]

    - 어떤 기능이 다 완성돼 다음 배포에 넣기로 했다면 develop 브랜치에 merge한다.

    - 다음, 아니면 다다음, 어쨌든 조만간에 배포할 기능을 개발하는 브랜치

    - 기능을 다 완성할 때까지 유지하고 다 완성되면 develop 브랜치로 merge한다.

    - 배포에 확실히 넣을 거라고 판단될 때 merge하고 결과가 실망스러우면 아예 버린다

    - 보통 개발자 저장소에만 있는 브랜치고 origin에는 push하지 않는다.

 3. release 브랜치    

    - 갈라져 나온 브랜치        : develop

    - 다시 merge할 브랜치    : develop, master

    - 브랜치 이름 규칙           : release-v.X.X

    - 배포할 수 있을 정도로 develop 브랜치가 준비돼 제품 배포를 준비하는 브랜치

    - 배포하는 데 필요한 버전 넘버, 빌드 일정 등의 메타데이터를 준비하고 사소한 버그도 잡는다. 

        이런 일을 release 브랜치에서 함으로써 develop 브랜치는 다음에 배포할 때 추가할 기능에 집중할 수 있다

    - master 브랜치에 있는 것을 배포하는 것으로 정의했으므로 먼저 release 브랜치를 master로 merge한다

    - 나중에 이 버전을 찾기 쉽도록 태그를 만들어 지금 master가 가리키는 커밋을 가리키게 한다

    - release 브랜치를 develop 브랜치에 merge하고 다음에 배포할 때 release 브랜치에서 해결한 버그가 적용되도록 한다. 

        (Release하는 도중에 사소한 버그를 수정했을수 있으므로)

    - 배포를 마친경우 release 브랜치는 더는 필요 없다. 삭제한다(Optional)

 4. hotfix 브랜치    

    - 갈라져 나온 브랜치            : master

    - 다시 merge할 브랜치        : develop, master

    - 브랜치 이름 규칙               : hotfix-v.X.X.Y --> v.X.X는 배포된 버전을 사용한다.

    - 미리 계획을 세워두지 않는다는 점만 빼면 hotfix 브랜치도 새로운 배포를 준비하는 것이기 때문에 release 브랜치와 비슷

    - 이미 배포한 운영 버전에 생긴 문제를 해결하기 위해 만든다

    - 운영 버전에 생긴 치명적인 버그는 즉시 해결해야 하기 때문에 문제가 생기면 master 브랜치에 만들어 둔 tag로부터 

hotfix 브랜치를 만든다

    - 버그를 잡았으면 다시 master에 merge하고 다시 develop 브랜치에도 merge해야 한다. 

그래야 다음에 배포할 때도 포함된다. release 브랜치를 마치는 방법과 같다.