github 잘못올라간 파일 커밋 히스토리 삭제하기

발생 배경

팀 프로젝트에서 사용 중인 supabase key 값이 포함된 파일이 커밋, 푸시가 된 상태에서 pr, merge가 완료 된 불상사가 발생했다.

merge가 된 파일을 각자 local 기능브랜치에 pull을 받으면서 각 브랜치에도 merge된 commit 기록이 생겼고,, 뒤늦게 발견했다.

 

 

🚨문제

PR은 Revert되어 해결했으나 각자 개인브랜치에 로컬에서 머지한 커밋 기록이 생겼고 해당 커밋에서 문제의 파일을 확인할 수 있었다.

 

 

❓원인

이번 프로젝트에서는 pr 규칙을 크게 설정하진 않고 화면공유를 해서 개인이 pr을 올리면 직접 merge 승인까지 했었다보니, 서로의 코드를 꼼꼼하게 살펴보지 않았던 것이 원인이었던 것 같다.

 

 

✅ 해결방법

모든 커밋에서 특정 파일을 제거하고 커밋을 재작성하는 명령어를 활용하였다.

 

1. git filter-branch 명령어

$ git filter-branch -force --index-filter 'git rm --cached --ignore-unmatch <파일 경로>' --prune-empty -- --all

 

2. 원격 저장소에 강제 Push

$ git push origin --force --all

 

 

프로젝트 레퍼지토리에 적용

1. 해당 명령어 입력 전 작업하고 있던 코드들 백업하기

 

2. 터미널에 명령어 입력

// 1
git filter-branch -f --index-filter "git rm --cached --ignore-unmatch supabaseClient.ts" --prune-empty -- --all
// 2
git filter-branch -f --index-filter "git rm --cached --ignore-unmatch ./src/app/supabaseClient.ts" --prune-empty -- --all

 

3. 원격 저장소에 강제 Push

// git push origin <브랜치이름> --force
git push origin feat/review --force

 

명령어 실행 후 원격의 해당 커밋에서 파일이 제거된 것을 정상적으로 확인할 수 있었다.

 

 

🥹 느낀점

이번 프로젝트 동안 민감한 키 노출, 파일 손상 등 깃 협업 관련 이슈가 많았는데 팀원들과 하나씩 해결하며 처음 접하는 명령어들도 사용해보게 되었다. 이번 경험을 통해서 협업 시 왜 코드에 대한 리뷰가 되어야 승인을 하는지, 리뷰 미작성 시 merge 비활성화 등 프로젝트 시작 초기에 팀원들과 소통해서 규칙을 잘 수립하고 시작하는 것의 중요성을 깨닫게 되었고 앞으로도 문제가 발생했을 때 덜 당황하고 의연하게 대처할 수 있을 수 있는 경험치를 쌓은 것 같다.

 

 

 

참고

https://edykim.com/ko/post/git-log-p-view-a-single-change-history-of-a-file/

https://gist.github.com/qweasd147/1a472e8bdb3a77d8a92d9b1e64299178

https://developheo.com/githube-jalmos-olrin-pail-hiseutoriggaji-sagjehagi/