문제 상황
-
Organization에서 작업하는 레포긴 했지만 백엔드 팀원이 나뿐이라 혼자 작업하고 있었고,
따라서master브랜치에서 모든 작업을 하고 있었다. -
이때 API 서버를 배포하는 과정에서 git에 올라가면 안될 파일이 올라갔다.
.gitignore에 해당 파일을 추가하고 캐시를 삭제해서 다시 커밋했지만,
커밋 이력에는 여전히 해당 파일의 정보가 남아있는 상태.
해결 방법
최신 커밋은 유지하면서, 해당 정보가 포함된 커밋만 삭제하고 싶었다.
따라서 rebase를 이용해 중간의 특정 커밋들을 삭제하여 해결했다.
Rebase?
리베이스는 변경사항을 별도의
patch로 만들어 저장해뒀다가,
base가 될 브랜치에 순서대로 적용하는 방식으로 작동한다.
그렇다면 이제 문제를 해결해보자.
-
git rebase -i {삭제하고 싶은 커밋들의 직전 커밋번호}
interactive 모드로 rebase를 시작한다.
해당 명령어를 입력하면 다음과 같은 vim 편집기가 열린다.cf.
직전 커밋으로 이동하는 것은 현재 HEAD가 가리키고 있는 지점을 바꿔주기 위함이다. -
vim 편집기가 열리면 직전 커밋번호의 다음 커밋부터 최신 커밋까지의 목록이 뜬다.
지우고 싶은 커밋번호의pick옵션을drop으로 바꿔준다.cf.
vi 편집기를 처음 다루는 사람을 위해 설명해보면,
편집이 가능한 insert 모드로 진입하려면 i 키를 누르고 수정하면 된다.
편집이 완료되면 esc 키를 누르고 insert 모드에서 나와서 :wq를 입력해주면 편집을 종료할 수 있다.
git rebase --continue
vi 편집기에서 적용한 사항에 더이상 추가적으로 변경할 것이 없다면 리베이스를 적용한다.
이후 git log로 로그를 띄워 리베이스가 적용되었는지 확인한다.
-
git push 로컬브랜치명 적용할원격브랜치명로 변경사항을 push한다.
만약 충돌이 발생한다면 끝에--force옵션을 적용한다. -
레포에서 확인해보면 해당 커밋이 사라져 있다.
마무리
뭔가 conflict가 발생할 때마다 rebase를 사용해 문제를 해결하는 것을 왕왕 보았다.
그때마다 원리도 모르고 무작정 문제 해결에만 급급해서 따라치기 바빴는데,
필요성을 느끼고 알아가며 사용해보니 비로소 rebase의 원리를 이해할 수 있었다.
새해에는 git 공부도 주기적으로 해야겠다고 다짐해본다.
