늦게 답변드려 죄송합니다. 박노아님의 말씀도 맞습니다. 소규모 프로젝트라면 디벨롭, 릴리즈 브랜치를 분할할 이유가 없습니다만 대규모 프로젝트라면 말이 다릅니다. 보통 프로젝트들의 프로세스는 '기획 -> 디자인 -> 개발 -> QA -> 출시'의 틀을 사용합니다. 다만, 차차 개발하다 보면 데이터들이 쌓여 버전별 브랜치들을 관리하는게 벅찰 때가 옵니다. 그래서 Git-Flow 전략을 사용합니다. develop 브랜치에서 파생된 보조 브랜치 (feature)에서 기능 작업의 개발을 마치고 develop 브랜치로 병합하게 됩니다. QA를 진행하기 위해 보조 브랜치 (release)를 생성하고, QA를 진행하며 생긴 버그들을 release에서 수정한 뒤, master와 develop 브랜치로 병합시킵니다. 그러고 완성된 프로젝트는 master 브랜치에서 배포가 됩니다. develop 브랜치에서는 계속 다음 버전을 출시하기 위해 개발하구요. 자세한 사항은, nvie.com/posts/a-successful-git-branching-model/ 에서 확인해주세요 :)
릴리즈를 디벨롭과 마스터에 머지한뒤에 릴리즈를 삭제하고, 마스터에서 핫픽스 브랜치 생성하는게 맞는거겠죠?
여기서는 hotfix branch를 develop,master에 merge한 직후라 develop에서 생성하신거 같은데
hotfix branch는 master branch에서 생성했어야 하는거죠?
바로코딩 저두그렇게생각해요
디벨롭 브런치와 릴리즈 브런치를 나눠논 이유가 뭔가요 ? 릴리즈에서도 변경 사항이 생긴다면 디벨롭 에서 다 끝내고 바로 마스터로 보내면 되지 않나용 ?
늦게 답변드려 죄송합니다.
박노아님의 말씀도 맞습니다. 소규모 프로젝트라면 디벨롭, 릴리즈 브랜치를 분할할 이유가 없습니다만 대규모 프로젝트라면 말이 다릅니다.
보통 프로젝트들의 프로세스는 '기획 -> 디자인 -> 개발 -> QA -> 출시'의 틀을 사용합니다.
다만, 차차 개발하다 보면 데이터들이 쌓여 버전별 브랜치들을 관리하는게 벅찰 때가 옵니다.
그래서 Git-Flow 전략을 사용합니다.
develop 브랜치에서 파생된 보조 브랜치 (feature)에서 기능 작업의 개발을 마치고 develop 브랜치로 병합하게 됩니다.
QA를 진행하기 위해 보조 브랜치 (release)를 생성하고, QA를 진행하며 생긴 버그들을 release에서 수정한 뒤, master와 develop 브랜치로 병합시킵니다.
그러고 완성된 프로젝트는 master 브랜치에서 배포가 됩니다.
develop 브랜치에서는 계속 다음 버전을 출시하기 위해 개발하구요.
자세한 사항은,
nvie.com/posts/a-successful-git-branching-model/ 에서 확인해주세요 :)