애플리케이션은 문제 있는 코드를 통합하여 타협할 수 있습니다. 이는 주요 브랜치에 미 완성된 작업을 우발적으로 통합했거나 자동화된 테스트를 통과한 중요한 버그를 간과했을 때 일어납니다.
이 글에서는 git revert
를 사용하여 안전하게 머지를 되돌리는 과정을 안내해드리겠습니다. 이를 통해 커밋 히스토리를 유지하고 프로젝트의 정합성을 보존할 수 있습니다.
git revert
작동 방식
git revert
는 Git의 되돌리기 명령어와 유사하게 생각할 수 있습니다. 그러나 git revert
명령어는 커밋을 지우거나 브랜치의 이전 상태로 이동하지 않습니다. 대신, 특정 커밋의 변경 사항을 되돌리는 새로운 커밋을 생성합니다.
커밋 해시 <commit_hash>
로 커밋을 되돌리는 문법은 다음과 같습니다:
git revert <commit_hash>
커밋과 그 해시 식별자를 함께 나열하려면 git log
명령어를 사용할 수 있습니다. git log
의 출력은 최신 커밋부터 오래된 커밋 순으로 나열됩니다:
예를 들어, 뺄셈 함수를 구현하는 커밋을 되돌리려면 다음 명령어를 사용합니다:
git revert 7ba24a3e62d4d37182428ccfaa070baa222b1151
git revert
를 사용하면 특정 커밋의 변경 사항을 되돌리면서 커밋 히스토리에 영향을 주지 않을 수 있습니다.
_git revert
_는 마법이 아니며, 커밋 이력에 따라 수동으로 해결해야 할 충돌을 초래할 수 있습니다.
_git revert
_의 수동 변경에 대한 장점
- 왜 충돌을 수동으로 해결해야 할지 모르는 이상
git revert
가 유용할까요? 수동으로 변경을 되돌리는 것이 더 쉬운 것 아닐까요? 그 장점을 살펴보겠습니다: - 이력 보존:
git revert
는 지정된 커밋의 변경을 되돌리는 새로운 커밋을 생성하면서 전체 커밋 이력을 보존합니다. 이는 변경과 되돌림의 투명한 이력을 유지하는 데 도움이 됩니다. - 원자적인 되돌림: 원자적이고 일관된 되돌림을 보장합니다. 수동으로 파일을 지우고 커밋을 하면 인간 오류의 위험이 있습니다.
- 충돌 인식: 원본 커밋에 종속된 통합이나 변경이 있으면 충돌을 통해 경고를 보장합니다. 이는不便할 수 있지만, 의도하지 않은 부작용을 방지합니다.
메타데이터: git revert
에 의해 생성된 새로운 커밋은 메타데이터와 커밋 메시지를 포함하여 되돌린 내용을 문맥적으로 설명하며, 이는 미래 이해에 도움이 됩니다. git revert
를 사용하지 않으면 이러한 문맥이 상실될 수 있습니다.
다른 상황에서의 마ージ 되돌리기
git merge feature
이 sections에서는 어떻게 마ージ를 되돌리는지 배웁니다. 예를 들어, main
브랜치로 feature
브랜치를 병합할 때 main
브랜치에서 명령을 실행하는 것으로 가정합니다: 우리가 여기서 배운 것은 적절한 이름으로 변경하여 어떤 두 브랜치에나 적용할 수 있습니다.
합병을 되돌리는 작업이지만 관련 커밋이 없는 경우
git merge
명령은 항상 새로운 커밋을 생성하는 것은 아닙니다. 커밋이 생성되는 것은 main
브랜치가 feature
브랜치로부터 분기된 경우에만입니다. 따라서 git revert
명령은 커밋을 필요로 하므로 이 경우 사용할 수 없습니다.
main
과 feature
브랜치는 main
에 새로운 커밋이 생성되어 feature
브랜치의 조상이 아닌 경우 분기됩니다. 다시 말해, feature
가 생성된 후 main
에 새로운 커밋이 생성된 경우입니다.
브랜치가 분기되지 않았다면, main
브랜치에서 git merge feature
명령을 실행할 때 Git는 fast-forward 합병을 사용합니다. 이는 main
브랜치의 HEAD
를 feature
브랜치의 HEAD
로 이동시킨다는 의미입니다.
이를 확인하려면 git merge
의 결과를 확인할 수 있습니다:
이러한 합병을 되돌리기 위해서는 main
브랜치의 HEAD
를 이전 위치로 되돌리는 것만 필요합니다. 이를 위해:
- 이전
HEAD
를git reflog
를 사용하여 식별합니다. - 이전
HEAD
로 되돌리려면git reset --hard <previous_head>
명령을 사용하세요. 여기서<previous_head>
는 이전HEAD
로 바꿔서 입력하세요.
git reflog
명령의 출력은 다음과 같을 것입니다:
이전 HEAD
를 식별하려면 “checkout: moving from feature to main”라고 나오는 줄을 확인하세요 (이는 우리의 브랜치 이름인 feature
와 main
을 쓰기 때문에).
이 경우, 이전 헤드는 fe59838
입니다. 메인 브랜치의 HEAD
를 거기로 되돌리고 머지를 취소하려면 다음 명령을 사용합니다:
git reset --hard fe59838
머지된 커밋을 되돌리는 경우
만약 main
브랜치와 feature
브랜치가 분岐되었다면, 두 브랜치를 머지할 때 새로운 커밋이 생성됩니다. 이를 머지 커밋이라고 합니다.
머지 커밋은 하나의 브랜치에서 다른 브랜치로의 변경 사항을 적용합니다. 이 경우, feature
의 변경 사항을 main
브랜치에 적용합니다.
main
브랜치의 변경 사항을 되돌리려면 머지 커밋에 대해 git revert
명령을 사용하세요. 이 명령은 새로운 커밋을 생성하여 머지로 인해 main
브랜치에 도입된 변경 사항을 취소하고, 머지 전의 상태로 되돌립니다.
우선, 머지 커밋의 해시를 식별해야 합니다. 이를 위해 git log
명령을 사용할 수 있습니다:
머지 커밋은 두 개의 부모를 가지므로, git revert
의 문법이 약간 다릅니다. main
브랜치에 대해 변경 사항을 되돌리려면 -m 1
옵션을 사용해야 합니다:
git revert -m 1 b8dab2c8611e324ed0d273133987415350e6d10d
커밋 되돌리기 시 충돌 해결
커밋을 되돌리는 데 충돌이 발생할 수 있습니다, 특히 되돌리는 커밋이 코드베이스의 후续 변경과 충돌할 경우입니다. 이러한 경우:
- Git은 되돌리기를 중지합니다: 우리는 수동으로 충돌을 해결해야 합니다. Git은 충돌이 발생한 파일을 표시하고 개입을 요청합니다.
- 충돌을 해결합니다: 우리는 각 충돌이 발생한 파일을 엽니다, Git이 표시한 충돌을 해결하고 변경 사항을 저장합니다.
- 해결된 파일을 스테이지합니다:
git add <file-path>
- 되돌리기를 계속합니다:
git revert --continue
결론
git revert
를 사용하여 머지 커밋을 되돌리면 커밋 기록 내의 모든 변경 사항과 수정 사항이 기록됩니다.
또한, git reset
와 git revert
를 적절한 상황에 어떻게 적용해야 하는지 이해하면 협업 워크플로우나 로컬만의 변경 사항을 고려할 때 더 나은 결정을 내릴 수 있습니다.
이 주제에 대해 더 알고 싶다면 아래의 자주 묻는 질문(Q&A) 섹션을 읽어보세요. Git에 대해 더 배우고 싶다면 다음 자료를 추천합니다: