어느 날 갑자기 내 Git에 Pull 대기 건수가 117건이나 떴다 (원인 분석과 안전한 해결책)

로컬에서 깔끔하게 작업하고 master나 develop 브랜치를 당겨오려고(Pull) 하는데, 갑자기 git pull 대기 건수가 100건 넘게 찍히는 황당한 경험 해보신 적 있으신가요? 
내가 안 한 작업이 이렇게나 많을 리 없는데 말이죠. 보통 이런 현상은 협업 과정에서 브랜치가 꼬이면서 git 커밋 뻥튀기가 발생하거나, 이미 반영된 커밋들이 git commit 중복 표시되는 오류 때문에 일어납니다. 
git pull 개수 오류나 git 커밋 꼬임 현상이 발생했을 때, 무작정 git pull을 받으면 대형 git 코드 충돌(Conflict)로 이어질 수 있어 위험합니다. 이때는 당황하지 말고, 내가 Pull을 받았을 때 순수하게 변하는 파일 목록만 깔끔하게 확인하는 것이 우선입니다. 
실무에서 안전하게 git 병합 전 파일 확인 및 히스토리를 점검하는 3단계 솔루션을 공유합니다. 

🚀 0단계. 원격 저장소 최신 정보 동기화

모든 확인 명령어에 앞서, 내 컴퓨터가 원격 저장소의 상태를 정확히 알 수 있도록 업데이트를 해줍니다. (내 로컬 코드는 전혀 건드리지 않으니 안심하셔도 됩니다.) 

git fetch origin

1단계. "Pull 받으면 최종적으로 내 파일들이 어떻게 바뀌지?" (최종 결과 확인)

중복 뻥튀기된 커밋들을 다 무시하고 순수하게 변하는 파일 목록만 깔끔하게 보고 싶을 때 사용합니다. git pull 전 변경 사항 확인을 위한 가장 똑똑한 명령어입니다. 

git diff --name-only HEAD..origin/develop

2단계. "도대체 누가 어떤 제목으로 117건이나 올린 거야?" (커밋 내역 확인)

117개의 커밋 메시지(제목)와 해시(커밋 번호)를 한 줄씩 요약해서 보고 싶을 때 사용합니다. 어떤 작업들이 들어있는지 히스토리를 파악하기 좋습니다. 

git log --oneline HEAD..origin/develop

3단계. "그 117건의 커밋들이 각각 어떤 파일들을 건드렸는지 볼까?" (상세 확인)

각 커밋별로 건드린 파일의 목록과 상태까지 함께 보고 싶을 때 사용합니다. 

git log --name-status --oneline HEAD..origin/develop

(목록이 너무 길어서 터미널 화면이 멈춘 것 같다면, 키보드 방향키 ↓로 내리면서 보거나 q를 눌러서 빠져나오시면 됩니다.)

💡 요약 및 실무 팁

결론적으로 실무에서는 히스토리가 어떻게 꼬였든 간에 "내가 지금 Pull을 누르면 내 코드가 실제로 어떻게 바뀌는가?"가 가장 중요합니다. 
따라서 git pull 대기 건수 숫자에 겁먹지 말고, 위에서 소개해 드린 git diff --name-only 명령어로 최종 변경될 파일만 쓱 훑어보세요. 변경 사항이 내가 아는 범위 내의 파일들이라면 안심하고 Pull을 받으셔도 됩니다!