git에서 생각보다 유용하게 쓰이는 기능이 바로 이번에 설명할 기능, amend
이다.
git에서 amend
란 직전에 했던 커밋에 추가적인 변경사항을 덮어쓰는 기능을 의미한다.
방금 했던 커밋을 원하는 대로 수정할 수 있다는 의미인데, 원격 저장소에 Push를 했더라도 amend
를 통해 수정사항을 반영할 수 있다.
예를 들어 파일 A, B를 커밋 했어야 했는데 실수로 파일 A만 커밋 했다고 가정하자.
만약 파일 B 커밋을 추가로 수행한다면 Git log가 더러워질 뿐만 아니라 다른 협업자들은 파일 A와 파일 B가 따로 커밋 된 데는 이유가 있지 않을까라는 오해를 할 수 있다.
따라서 이 경우 파일 A를 반영한 커밋에 "파일 B를 추가하여" 커밋을 수정함으로써 보강하는 저장 버튼 같은 역할이 있으면 좋을 것이고 이 버튼이 바로 amend
인 것이다.
amend
를 쓰는 경우는 아래와 같다.
FINANCIAL
이라고 했는데 회의 결과 FI
로 바꾸기로 했다.마지막으로 amend
시 해시 체크섬 값이 변한다는 사실도 알고 가자.
amend를 "덮어쓰기"라고는 말했지만 동작 과정을 더 정확히 말하자면 "새로운 커밋을 생성하고 그곳에 변경사항과 이전 커밋을 포함시킨 뒤 이전 커밋을 대체하는" 과정을 거친다.
따라서 amend를 수행할 경우 커밋의 해시 체크섬 값도 바뀌게 된다.
필자는 Amend를 하기 전 커밋
이라는 문구를 추가하여 커밋했다.
Git Log에 해당 커밋이 생성되었음을 볼 수 있다.
누락된 문구가 직전 커밋(Amend 이전 커밋)에 포함되어야 한다고 가정하자.
커밋할 파일 내용은 아래와 같다.
위 사진에서 볼 수 있듯이 Message도 "Amend 이후 커밋"이라고 명시했다.
체크 표시하고 커밋 메시지까지 기록했다면 Commit
버튼을 클릭하자.
위 사진에서 볼 수 있듯 Amend 이전 커밋
이었던 커밋 메시지가 Amend 이후 커밋
으로 변경되었음을 볼 수 있다.
(실제 커밋 내용도 변경되었음을 확인할 수 있다)
# 1. 변경 된 파일들 Staging
git add . # '.' 대신 Staging할 파일들을 리스트업 해도 됨
# 2. Staging 된 파일들 Amend
git commit --amend
정리하자면 수정한 내용을 Staging Area에 올린 뒤(Staging 한 뒤) Commit 한다는 전체적인 구조는 바뀌지 않으나 --amend
옵션을 활용해 Amend를 수행할 수 있는 것이다.
git push -f # -f 대신 --force 옵션을 사용해도 됨
amend
를 통해 커밋을 수정한 후 git push
를 수행하면 바로 변경된 커밋이 원격 저장소에 반영된다.....라는 것은 정말 말도 안 되는 틀린 말이다.
--amend
를 사용한다면 위에서 말했듯 커밋 아이디(해시 체크섬)도 바뀐다.
즉, Git 입장에선 원래 존재하던 커밋이 없어지고 갑자기 그 자리에 이상한 커밋이 새로 생성된 것이다.
이를 Git에서는 "현재 Push할 커밋과 원격 저장소의 HEAD 커밋이 연결되어 있지 않다"라고 보고 에러를 발생시킨다.
따라서 Amend 커밋을 반영하기 위해선 -f
나 --force
옵션을 활용해 강제로 push 시켜주어야 한다.
(추가로 앞으로 원격 저장소 Git Log가 변경되는 모든 작업에 대해선 무조건 -f
나 --force
옵션이 필요하다는 것을 알아두면 좋다)
Amend부터는 사실 IntelliJ 같은 개발 툴에서 GUI를 통해 작업하기엔 조금 까다롭다.
실제로 IntelliJ에서 Amend 한 커밋을 Push 할 경우 Git Log를 깔끔히 만들기 상당히 까다롭다는 것을 알 수 있다.
여기부터 공부하며 왜 필자가 GUI를 애용하다 Git 명령어를 하나씩 배우고 CLI로 넘어가고 있는지 조금이라도 알았으면 좋겠다.