5~6 명 정도되는 소규모 파트인데....
브랜치 관리를 어떻게 해야될지 고민입니다.
원격 master를 개인 저장소에 각자 포크해서 작업한 뒤 원격 master로 pr하는게 정석?으로 알고 있는데...
일일이 코드 리뷰할 여력이 안되서 굳이? 라는 생각이 듭니다.
저도 정석적인 방법으로 개발해본적은 없구요...
적당히 dev 따고, merge를 남발하니 로그 그래프가 개판이 되네요.
개인별 또는 추가되거나 구현되는 기능별 브랜치를 만들고,
master나 dev로 rebase하고 merge commit은 최소화하면 어떨까 생각중입니다.
pr기반으로 커밋을 쌓아가는게 맞는걸까요?
참고로 상품화하거나 서비스하는건 아니고 선행개발쪽이라 철저히 내부용이긴 합니다.
저 같은 경우는 master -> release -> development -> version/* -> feature or bug fix
이런식으로 "혼자서" 하는 중입니다.
version/* 으로 pr보낸 feature나 bug fix는 CI에서 테스트 하고 통과되면 머지 할 수 있게 알려주고요.
version/*이 development로 머지 되면 개발버전을 빌드해서 배포하는 식으로 flow를 잡고 있는데
commit 로그가 상당히 지저분 해집니다.
PR을 기반으로 commit 로그를 쌓아나가야 좋을 것 같긴 한데 방법이 궁금하네요..
클리앙 github 프로젝트를 이런식으로 운영하면서 여럿이서 협헙해보는걸 익히면 어떨까 싶습니다.
실제 예전 팀에서는 그냥 branch 바로 따서 pr 하거나 바로 머지했는데 나중에 시간 지나니 어떤 branch 가 머지가 다 끝난건지 헤갈리더군요. (중간에 퇴사하고 그러면 정말 관리 안됨)
실제로 해보니 정말 상황마다 다 달라서 이걸 지켜내기가 불가능하더군요.
특히나 릴리즈 날짜가 규칙적으로 매번 정해지고, 고객사가 원하는 기능을 다음 릴리즈 날까지 기다려준다는 조건이 없으면..
사실상 이대로 하는게 불가능했습니다.
하지만 기본적인 틀은 최대한 이 틀을 따르려고 하고 있어요.
git이라는 게 소스 형상관리도 중요하지만, 히스토리 정의도 중요해서요
제 생각좀 적어봤습니다
그리고 5명이 넘으면 그렇게 작지도 않은걸요 ㅎ...