pull, fetch는 모두 원격 저장소의 커밋을 로컬 저장소로 가져오는 역할을 합니다.
다만 차이점은, pull은 fetch + merge 작업이 동시에 발생합니다.
아마 당연하게도 fetch를 습관화하는 분들이 있을 것 같습니다.
저 또한 조금은 불편하지만 안전성이 좋은 fetch를 추천하고 싶습니다.
- Pro Git에서 많은 인사이트를 받았습니다.
fetch
fetch는 원격 저장소의 커밋들을 로컬 저장소로 가져옵니다.
하지만 코드의 merge 과정은 발생하지 않아 로컬 저장소의 내용이 변경되지 않습니다.
그래서 fetch 이후의 행동이 자유롭다는 장점이 있습니다.
주로 merge 하기 전 신중함이 필요한 상황에서 fetch를 사용하면 좋습니다.
pull
pull은 원격 저장소의 커밋을 가져오는 동시에 로컬 저장소에 merge 합니다.
자동으로 fetch + merge 과정을 진행하기 때문에 편리합니다.
하지만 자동으로 병합되기 때문에 충돌이 발생할 수 있습니다.
🔎 Source Control
fetch 명령어를 습관화하면서 익숙해진 도구를 하나 소개하고 싶습니다.
아마 많이들 아실듯한 VScode의 Source Control입니다.
예전엔 주로 CLI가 편리해서 애용했지만 최근 GUI에 대한 생각이 바뀌었습니다.
전반적인 프로젝트 상황을 파악하기에 GUI가 정말 편했기 때문입니다.
그래서 현재는 GUI + CLI 조합으로 버전 관리를 하고 있습니다.
만일 하나의 방식에만 익숙했다면 나머지도 배워보는 것을 추천합니다.
CLI와 GUI 모두 장단점이 있어 상호 보완적으로 활용할 수 있습니다!
결론
정답은 없지만 fetch를 습관처럼 이용하는 것이 좋습니다.
번거롭다는 단점 외에 안정적인 협업 측면에서 장점이 크기 때문입니다.
pull은 커밋을 확인할 필요가 없고, 충돌 문제가 없을 때 사용합니다.
하지만 이러한 확신에도 pull은 예상하지 못한 문제가 생길 수 있습니다.
그래서 pull을 사용할 상황에서도 습관적으로 fetch를 하는 것을 추천합니다.
💡 불편함에서 오는 편리함
최근 함께 자라기나 클린 아키텍처를 보며 생산성에 관한 사고방식이 달라졌습니다.
단기적이며 개인적이던 관점을 보다 장기적이며 협동적인 관점으로 넓힐 수 있었는데요.
프로젝트가 커질수록 비용은 지수 형태를 보이지만 생산성을 오히려 로그 형태를 보입니다.
둘을 합하면, 지저분한 코드에 대한 대가는 폭발적일 수 있음을 느낍니다.
하지만 반대로 말하면, 좋은 코드와 설계도 그 효과가 폭발적일 수 있다는 사실입니다.
(심지어 비용은 인원수에도 비례하며 늘어나니까요.)
이를 몸소 느낄 수 있었던 계기들이 많았습니다.
모호한 변수명 때문에 팀원의 코드 파악에 많은 시간을 허비한 적도 있었고,
반면 잘 쓰여진 커밋 덕분에 많은 시간을 아낀 적도 있었습니다.
심지어는 제가 예전에 쓴 커밋 메시지 덕분에 시간을 아낀 적도 많았습니다..
이러한 경험 덕분에 초기 코드와 설계의 중요성을 점점 느끼게 됩니다.
이번에 Git을 공부하면서도 비슷한 느낌을 받았습니다.
프로젝트에 있어 잘 관리된 커밋만큼 업무 흐름 파악에 도움이 되는 것이 없었습니다.
또 개인적으로는 좋은 커밋을 작성하려는 노력이 업무 구분을 확실하게 만들어 줬습니다.
마치 좋은 함수명을 고민하며 자연스럽게 클린 코드를 지키는 것처럼 말이죠.
그래서 요즘 커밋을 신경쓰느라 생기는 작은 불편함 들을 즐기게 되었습니다.
훗날 누군가가 제 커밋을 통해 많은 시간을 아낄 수도 있다는 믿음을 가지면서요. 😊