이 문서는 가리사니 개발자 포럼에 올렸던 글의 백업 파일입니다. 오래된 문서가 많아 현재 상황과 맞지 않을 수 있습니다.
git 탐구 시리즈
일반적으로 많이 볼 수 있는 플로우
강의 2~3 장에서도 약간 언급되긴 하지만 프로젝트의 규모가 크지 않다면 위 플로우는 오히려 더 비효율적이 될 수 있습니다.
그래서 이번장에서는 필자가 생각해본 소규모 프로젝트용 git 플로우를 설명해 보도록 하겠습니다. (필자의 생각임으로 각 프로젝트 별 가장 알맞은 프로우를 직접 디자인 해보시기 바랍니다.)
master : 1개 - 사이클 : 프로젝트 폐기까지
DEV : 1개 - 사이클 : 프로젝트 폐기까지
hotfix : 여러개 - 사이클 : 해당 핫픽스를 만들고 master에 병합까지.
feature : 여러개 - 사이클 : 해당 신규/수정 작업을 끝내고 DEV에 병합까지.
프로젝트의 규모가 작으면서 지속적으로 개발작업이 들어오며, 간혹 핫픽스가 발생할 때 쓸만한 플로우라고 생각합니다. 핫픽스의 경우 master로부터 가장 최근 태그를 꺼내와서 적용 후 master에 병합합니다. 개발/수정의 경우 DEV로부터 피쳐를 만들고 각각 작업 후에 적용할 것만 DEV로 합치고 테스트 한 후 다시 master에 합쳐 배포합니다. (즉, 게시판, 고객정보, 메인화면변경 이렇게 3개를 피쳐로 개발중인데 3일 후 게시판과 고객정보만 적용해야할 경우 게시판, 고객정보 피쳐를 DEV에 병합한 후 테스트 합니다.) 마스터에 병합 후 운영 서버에 반영되었다면 새로운 태그를 작성합니다. (그리고 해당 피쳐는 삭제합니다.)
master : 1개 - 사이클 : 프로젝트 폐기까지
dev unit: 여러개 - 사이클 : 해당 신규/수정 작업을 끝내고 master에 병합까지.
hotfix : 여러개 - 사이클 : 해당 핫픽스를 만들고 master에 병합까지.
프로젝트 규모가 매우 작으면서 핫픽스나 아주 소규모 작업외에는 별다른 작업이 들어오지 않을때 DEV로 병합하는 과정을 없엔 플로우 입니다. 이 프로우는 DEV에 병합하는 과정이 없어 좀 더 간결하지만 큰 작업을 할땐 매우 위험합니다. DEV같이 중간 병합 테스트를 할 수 있는 환경이 없어 master에서 해야하는데.... 핫픽스도 들어오고 전체적인 기획이 바뀌어 작업이 크게 변경 된다면 상당한 혼란을 초래할 수 있습니다.