아직도 Git 안 쓰세요. 시대에 맞지 않게 아직도 기억에 의존하나요
제목을 반대로 적어 보았습니다. 결국은 어떤 방식을 사용 했을 때 더 효율적이냐 많이 변화 시켰는데 실제 변화된 것이 있느냐.
- 웹사트의 예를 들면 화면단에서 변한것이 아무것도 없이 내부적으로만 변경됨
- 내부적으로 변경이 많이 되었다는데 시간 차이는 별 다른게 없음
- 머지 한다고 충돌 난다고 더 오래 걸리면?
소규모 팀에서 Git을 쓰지 않으면 시대에 뒤처진다고요? 상황에 따라 Git은 오히려 불필요한 복잡성을 더할 수 있으며 아래 경우라면 Git 없이도 충분합니다.
5명도 안되는 소규모 팀인 경우
매일 얼굴 보고 대화하는 사이라면 브랜치 전략이나 PR 리뷰 프로세스는 그냥 회의 한 번이면 해결됩니다
팀원 간 소통이 원활하고 배포가 빠른 경우
코드 올리기 전에 "나 이거 수정할게요" 한 마디면 충분하고 FTP 직접 올리는 게 오히려 더 빠를 수 있습니다
에디터 자동저장과 별도 백업이 이미 갖춰진 경우
VSCode 히스토리나 서버 스냅샷이 있다면 Git의 버전 관리 이점이 크게 줄어듭니다
업무 영역이 자연스럽게 나뉜 경우
A는 프론트 B는 백엔드처럼 겹치는 파일이 거의 없다면 충돌 관리 자체가 필요 없습니다
공통 파일 수정 전 항상 팀에 공유하는 문화가 있는 경우
슬랙이나 카카오톡으로 "공통 config 건드릴게요" 한 마디면 Git의 충돌 방지 역할을 대신할 수 있습니다
자신의 코드와 변경 이유를 머릿속에 담아두는 경우
왜 이 코드를 썼는지 본인이 명확히 알고 설명할 수 있다면 커밋 메시지에 의존할 필요가 없습니다
파일 병합을 직접 처리할 수 있는 경우
충돌 나는 부분이 뭔지 파악하고 직접 합칠 수 있다면 merge 도구 없이도 충분합니다
코드 변경을 말로 설명할 수 있는 경우
"헤더 높이 조정하고 로그인 버튼 색 바꿨어요" 정도면 PR 설명보다 직접 말하는 게 훨씬 빠릅니다
배포 자동화가 이미 구축된 경우
쉘 스크립트 하나로 서버 배포까지 끝난다면 Git 기반 CI/CD 파이프라인은 오버엔지니어링일 수 있습니다
실수했을 때 직접 수습하는 문화인 경우
문제가 생기면 바로 고치고 팀에 공유하는 문화라면 rollback 기능보다 그게 더 건강한 팀입니다
팀원 퇴사 시 인수인계가 제대로 되는 경우
문서화와 직접 인수인계가 잘 된다면 Git log 뒤지는 것보다 훨씬 명확하고 빠릅니다
로컬개발시 유용한 git을 사용하는것이 맞다면 제미니에게 위내용을 주고 git 명령 한줄이면 되는것으로 반박해 달라고 하면 쏟아 집니다.
실수로 파일 삭제하고 내용 수정되고 누가 했는지도 모르고 주석도 없는 그런 상황에서 진가를 발휘 합니다.
누가 뭘 했는지도 볼 수 있고 오늘 얼만큼 수정 했는지도 볼 수 있는 장점?을 가지고 있음.