들어가며
git을 사용하다 보면 자주 쓰는 명령어 외에는 왠지 손이 잘 가지 않는 명령어들이 있습니다. git revert와 git cherry-pick이 저에게는 딱 그런 명령어였는데요. 필요한 순간이 오면 분명히 써야 하는 건 알겠는데, 익숙하지 않으니 잘못될까봐 선뜻 손이 가지 않았습니다.
그리고 실제로 얼마전 프로젝트에서 revert를 사용했다가 작업이 날아간 경험을 하기도 했습니다. 한 브랜치에서 특정 커밋을 revert하고, 다른 브랜치에서는 동일한 작업을 다시 진행한 뒤 각각 main에 머지했더니, 분명히 다시 작업한 내용이 있었음에도 revert된 상태가 적용되어 작업이 통째로 날아가버린 것이었습니다. 그때는 왜 그렇게 됐는지도 몰랐기 때문에 무척 당황스러웠던 기억이 납니다.
그 이후로 git revert와 git cherry-pick에 대해 제대로 알아야겠다는 생각이 들었습니다. 이번 글에서 제가 공부한 내용과 제가 겪은 것처럼 의도치 않은 상황이 생기지 않도록 알아두어야 할 내용들도 함께 정리해보았습니다.
git revert란?
git revert는 이전에 만들어진 커밋의 변경 사항을 되돌리는 새로운 커밋을 생성하는 명령어입니다. Git 공식 문서에서는 이렇게 설명하고 있습니다.
"Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them." — git-scm.com
즉, 특정 커밋을 없던 일로 만드는 것이 아니라, 그 커밋의 변경을 상쇄하는 새 커밋을 추가하는 방식입니다. 이 점이 가장 중요한데요. 기존 히스토리를 삭제하거나 수정하지 않는다는 것이 git revert의 핵심입니다.
그렇기 때문에 이미 공유된 브랜치, 예를 들어 main이나 develop처럼 여러 사람이 함께 사용하는 브랜치에서 작업을 되돌릴 때 git reset 대신 git revert를 써야 합니다. git reset은 히스토리 자체를 바꾸기 때문에 협업 환경에서는 위험할 수 있기 때문입니다.
git revert 사용법
# 특정 커밋을 revert하기
git revert <commit-hash>
# 커밋 메시지 편집 없이 바로 revert하기
git revert --no-edit <commit-hash>
# revert 커밋을 바로 만들지 않고 변경 사항만 스테이징하기
git revert -n <commit-hash>
git revert --no-commit <commit-hash>커밋 해시는 git log로 확인할 수 있습니다.
git log --oneline실행하면 아래와 같이 커밋 목록이 나오는데요. 여기서 되돌리고 싶은 커밋의 해시 값을 복사해 사용하면 됩니다.
a1b2c3d 버그 수정: 로그인 유효성 검사
e4f5g6h 기능 추가: 다크모드 지원
i7j8k9l 초기 세팅revert를 실행하면 기본적으로 커밋 메시지를 편집할 수 있는 에디터가 열립니다. 자동으로 Revert "원래 커밋 메시지" 형식으로 메시지가 작성되는데요. Git 공식 문서에서는 단순히 자동 생성된 메시지를 그대로 쓰는 것보다, 왜 revert를 했는지 이유를 적어두는 것을 강력히 권장하고 있습니다.
revert 후 같은 작업을 다시 머지하면 사라진다
이 부분이 바로 제가 실수했던 지점인데요. 이 현상은 생각보다 많은 개발자들이 경험하는 상황이어서, Git을 만든 Linus Torvalds가 직접 이에 대한 how-to 문서(revert-a-faulty-merge)를 작성할 만큼 잘 알려진 현상이기도 합니다. git revert의 특성을 이해하면 왜 그런 일이 생기는지 알 수 있습니다.
revert는 단순히 코드의 변화를 되돌리는 것이 아니라, Git의 히스토리 입장에서는 해당 커밋이 이미 반영된 것으로 기억합니다. 그래서 이런 상황이 생기는 것이죠.
feature브랜치를main에 머지 (A 작업 포함)- A 작업에 문제가 생겨
main에서 revert - 다른 브랜치에서 A 작업을 새로 진행 후
main에 머지 - 결과: A 작업이 적용되지 않음
이렇게 되는 이유는, Git이 머지할 때 두 브랜치의 공통 조상을 기준으로 변경 사항을 계산하기 때문입니다. revert 커밋이 이미 히스토리에 존재하기 때문에 나중에 동일한 변경 내용을 다시 머지해도 이미 적용된 것으로 간주하고 무시하게 됩니다.
이 상황을 해결하는 방법은 두 가지입니다.
방법 1: revert를 다시 revert하기
가장 일반적인 해결 방법은, revert 커밋 자체를 다시 revert하는 것입니다.
# revert 커밋의 해시를 확인하고
git log --oneline
# revert 커밋을 다시 revert
git revert <revert-commit-hash>이렇게 하면 "revert의 revert"가 되어 원래 작업이 다시 살아납니다. 단, 이 방법은 그사이에 다른 작업이 많이 쌓였다면 충돌이 생길 수 있으니 주의가 필요합니다.
방법 2: 브랜치를 새로 만들어 작업하기
revert된 작업을 다시 반영해야 한다면, 브랜치를 새로 생성해서 처음부터 다시 작업하는 방법도 있습니다. 다소 번거롭게 느껴질 수 있지만, 히스토리가 깔끔하게 유지된다는 장점이 있습니다.
git cherry-pick이란?
git cherry-pick은 다른 브랜치에 있는 특정 커밋을 현재 브랜치에 그대로 적용하는 명령어입니다. 말 그대로 체리를 하나씩 골라 담듯이, 전체 브랜치를 머지하지 않고 원하는 커밋만 선택적으로 가져오는 것이죠.
Git 공식 문서에서는 cherry-pick을 이렇게 설명하고 있습니다.
"Apply the changes introduced by some existing commits" — git-scm.com
cherry-pick이 유용한 상황은 주로 아래와 경우들입니다.
- 개발 브랜치에서 버그를 수정했는데, 이 수정 사항만 빠르게 main에 반영해야 할 때
- 실수로 잘못된 브랜치에 커밋했을 때, 올바른 브랜치로 그 커밋만 옮겨야 할 때
- 오래된 브랜치가 머지되지 않고 닫혔을 때, 그 중 일부 커밋만 살리고 싶을 때
git cherry-pick 사용법
# 특정 커밋을 현재 브랜치에 적용하기
git cherry-pick <commit-hash>
# 여러 커밋을 한 번에 적용하기
git cherry-pick <commit-hash-1> <commit-hash-2>
# 커밋 범위를 지정해서 적용하기 (A는 포함되지 않고 B까지 적용)
git cherry-pick <commit-hash-A>..<commit-hash-B>cherry-pick이 성공하면 해당 커밋의 변경 내용이 현재 브랜치에 새로운 커밋으로 추가됩니다. 이때 커밋 해시는 원본과 다른 새로운 해시가 부여된다는 점도 알아두면 좋습니다.
유용한 옵션도 몇 가지 있습니다.
# 커밋 메시지를 편집하면서 cherry-pick하기
git cherry-pick -e <commit-hash>
git cherry-pick --edit <commit-hash>
# cherry-pick 결과를 커밋하지 않고 스테이징 상태로 두기
git cherry-pick -n <commit-hash>
git cherry-pick --no-commit <commit-hash>
# 어떤 커밋에서 가져온 것인지 원본 커밋 정보를 메시지에 추가하기
git cherry-pick -x <commit-hash>특히 -n 옵션은 여러 커밋의 변경 사항을 하나의 커밋으로 합치고 싶을 때 유용합니다. 각 커밋을 --no-commit 옵션으로 적용한 뒤 마지막에 한 번만 커밋하면 되기 때문입니다.
cherry-pick 중 충돌이 생겼을 때
cherry-pick 도중 충돌이 발생할 경우 revert나 rebase와 동일한 방식으로 해결하면 됩니다.
# 1. 충돌 파일을 직접 수정한다
# 2. 수정한 파일을 스테이징
git add <수정한 파일>
# 3. cherry-pick 이어서 진행
git cherry-pick --continue
# 중간에 그냥 취소하고 싶다면
git cherry-pick --abort
알아두면 좋은 팁과 유의사항
커밋 해시를 빠르게 확인하는 법
cherry-pick이나 revert를 사용할 때 가장 먼저 필요한 것이 커밋 해시인데요. 아래 명령어를 활용하면 좀 더 편하게 확인할 수 있습니다.
# 한 줄로 간결하게 보기
git log --oneline
# 브랜치 그래프와 함께 보기
git log --oneline --graph --all
# 특정 브랜치의 커밋만 보기
git log --oneline feature-branchcherry-pick은 중복 커밋을 만들 수 있다
herry-pick은 원본 커밋의 변경 내용을 새로운 커밋으로 복사하는 방식이기 때문에, 나중에 해당 브랜치를 머지하게 되면 동일한 변경 내용이 두 번 존재하는 상황이 생길 수 있습니다. 때문에 cherry-pick은 일회성으로 특정 변경을 가져와야 할 때 사용하는 것이 좋고, 브랜치 전체를 반영하는 데는 머지나 리베이스를 사용하는 것이 더 적합합니다.
revert는 히스토리를 보존한다는 걸 항상 기억하기
git reset과 헷갈리기 쉬운데요. reset은 히스토리 자체를 되돌리는 반면, revert는 히스토리를 유지하면서 새 커밋으로 변경을 상쇄합니다. 공유 브랜치에서는 항상 revert를 사용하는 것이 안전합니다.
revert한 내용을 다시 반영할 때는 반드시 확인하기
앞서 설명했던 것처럼, revert한 커밋을 다시 반영하려 할 때는 단순히 같은 작업을 다시 하는 것만으로는 적용되지 않을 수 있습니다. 이 점을 잊지 않는 것이 정말 중요한 이유는 실제로 많은 분들이 이 부분에서 혼란을 겪기 때문입니다. revert가 포함된 브랜치에 변경을 다시 반영할 계획이 있다면, revert 커밋을 먼저 다시 revert한 뒤에 진행하는 것을 권장합니다.
마치며
revert와 cherry-pick은 자주 쓰는 명령어는 아니지만, 필요한 순간에 제대로 알고 쓰는 것과 모르고 쓰는 것의 차이가 꽤 크게 느껴지는 명령어인 것 같습니다. 특히 revert는 히스토리를 되돌리는 게 아니라는 점만 잘 기억해두셔도 저처럼 작업을 날리는 일은 없지 않을까요?
오늘도 읽어주셔서 감사합니다. 🙇♀️
참고문헌
git revert (git-scm.com)
git cherry-pick (git-scm.com)
How to revert a faulty merge (git-scm.com)
Git Cherry Pick (Atlassian Git Tutorial)