1. 깃허브 배포 전략 및 문제를 파악하다. 사내에서 담당하게 된 프로젝트의 Git 브랜치 구조를 처음 봤을 때, 바로 개선이 필요하다고 생각했습니다. 처음 본 문제main (운영 서버) / develop (개발 서버) 브랜치만 존재했습니다.main과 develop이 동기화되지 않은 부분이 있었습니다.전달받은 main 배포 방식은.. develop 작업 파일 수동 복붙이었습니다. 왜 이런 상황이 됐을까? 더 파보니 이전 작업자분들도 나름의 이유가 있었습니다. 로컬에서 CRUD 테스트가 불가능 (보안 제약으로 조회만 가능) 즉, 기능 검증을 위해서는 무조건 develop에 올려야만 했습니다.feature 브랜치 없이 모두가 develop에 직접 push 했음.배포 제외 기능도 develop에 계속 쌓임..

문제github에서 삭제되었다고 전달받은 브랜치가 git fetch를 해도 남아있었습니다.아니 git fetch 하면 다 최신화 아니냐? 어이없네 하면서 0과 1밖에 모를놈 따위에게 예민하게 굴었는데요! 좀 알아보니까 이유를 발견했습니다. 원인이유는 origin에 올렸던 reference 값은 fetch를 하더라도 남아있어서였습니다.fetch는 원격의 새로운 변경사항은 가져오지만, 삭제된 브랜치의 로컬 참조는 자동으로 제거하지 않기 때문입니다. 해결prune 이라는 "가지치기" 뜻을 가진 명령어를 사용해주면 해결됩니다.# prune(가지치기 명령어)를 사용git fetch --prune origin# 짧게도 가능git fetch -p origin 자동으로 fetch 할 때 마다 같이 되게 하는법은 다음과..