내가 한동안 이거에 빠삭 했었지


개발하다보면 니가 보통 영구적인 두개 브랜치를 유지하게 된다. 하나는 마스터라 부르고 다른 하나는 디벨롭 이라 부르자. 마스터 브랜치는 릴리즈 된 것들만 모여 있다고 보면되고, 디벨롭 브랜치는 기능 완성된 것들만 머지 한다 보면 됨.



필요에 따라 대략 두세 종류의 임시 브랜치 들이 있다. 1. 새 기능을 위한 피쳐 브랜치, 2. 릴리즈 대상 버그픽스 브랜치, 3. 릴리즈 캔디데이트 브랜치

얘들은 모두 잠시 브랜치를 만들었다가 다시 머지하고 끝내는 브랜치 들이지



최초 마스터로 부터 디벨롭 브랜치를 하나 만들고, 모든 피쳐 브랜치는 디벨롭에서 브랜칭해서 개발 끝나면 디벨롭으로 머지

이러다가 때가 되면 마스터 브랜치에서 릴리즈 캔디데이트 브랜치를 만들고 디벨롭 브랜치를 그리로 머지 하여, 닝겐들에게 릴리즈 캔디데이트를 써보라고 권하는 거지


아무 문제 없으면 릴리즈 캔디데이트 브랜치를 마스터 브랜치로 머지하고 그것을 릴리즈 함



이러다가 버그가 보고되면 릴리즈 포인트에서 브랜치해서 버그픽스 브랜치를 만들고 고친 후 다시 마스터로 머지. 이때 이 변경은 디벨롭으로 다시 머지 되어야 됨



이게 브랜치 전략의 모든 것이지. 이것만 꽤차고 있으면 버전 컨트롤은 이만 하산해도 되는 수준





근데, 내가 continuous delivery 시스템과 프로세스를 도입하면서 저 모델을 버리게 됨. 걍 맘 먹으면 아무떄나 시도없이 릴리즈 하고, 굳이 버전 번호 같은거 달지도 않는다! 


진정한 상남자의 개발법이지 ㅇㅇ