VCS

VCS

VCS 선택

요즘의 상황이라면 GIT 이외의 다른 VCS는 생각할 필요가 없는 듯 합니다.

만약 이미 다른 VCS를 쓰고 있다면 GIT으로 모두 컨버팅 하는 것을 추천합니다.

커밋 작성하기

여기는 제 개인적인 생각입니다.
현재 운영중인 프로젝트의 경우 오픈될 일이 없는 회사의 비지니스 프로적트 입니다.
그러다 보니 불특정 다수의 개발자가 프로젝트 중간에 참여할 일이 없습니다.
지난 몇년간 약 1~2줄 내외, 80자 미만(대부분 30자 미만)으로 커밋메세지를 작성하여 올려놓았을 때
실제로 그 커밋 메세지를 열어보며 무언가를 한 적이 별로 없었습니다. 이유는 대부분의 경우 매우 많은 팀원과 같은 프로젝트에서 진행하는 것이 아니기 때문에
간단하게 쓴 메세지만으로도 대략적으로 어느부분에서 문제가 생길 것인지 예측이 가능했습니다.
다만 이 말은 대충써라 또는 대충써도 된다는 말은 아닙니다.
짧더라도 어느부분이 왜 바꼈는지 정도만 남겨도 되었다 정도 입니다.
현재 제가 작성하는 메세지의 경우 대략
“관리자 페이지 / 상품관리 메뉴 / xxx 기능 추가 “
정도의 메세지로 “GND / LNB / 변경 내역” 정도의 패턴으로 작성하고 있습니다.
이 부분은 아마 사람이 더 늘어나게 되거나 비지니스 복잡도가 더 증가하게 된다면 바뀌게 될 가능성이 있지만
당분간은 크게 바뀌지 않을 것 같습니다

브랜치 관리 전략

현재 크게 사용되는 브랜치 전략은 위의 링크에 나와있는 3개의 전략입니다
지금 회사에서 사용중인 전략?은
모두 마스터에서 작업하는 것입니다 (페이스북이 이렇게 한다고 카더라)
다만 작업 분량이 많고 다른 기능과의 연계성이 떨어지는 것의 경우
별도의 로컬 브랜치를 생성한 후 어느정도 기능이 완성될 떄 까지
주기적으로 마스터 브랜치와 동기화 해가면서 작업한 이후에
마스터에 merge 합니다
마스터 브랜치의 경우 상시 배포가능한 상태로 유지되어야 합니다
기능이 완성되지 않은 경우 완성되지 않았다고 정상?적인 에러 메세지를 출력하는 상태를 유지 해야합니다

추천 사이트