Git Revert Merge Commit: 가이드 및 예제

애플리케이션은 문제 있는 코드를 통합하여 타협할 수 있습니다. 이는 주요 브랜치에 미 완성된 작업을 우발적으로 통합했거나 자동화된 테스트를 통과한 중요한 버그를 간과했을 때 일어납니다.

이 글에서는 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 명령은 커밋을 필요로 하므로 이 경우 사용할 수 없습니다.

mainfeature 브랜치는 main에 새로운 커밋이 생성되어 feature 브랜치의 조상이 아닌 경우 분기됩니다. 다시 말해, feature가 생성된 후 main에 새로운 커밋이 생성된 경우입니다.

브랜치가 분기되지 않았다면, main 브랜치에서 git merge feature 명령을 실행할 때 Git는 fast-forward 합병을 사용합니다. 이는 main 브랜치의 HEADfeature 브랜치의 HEAD로 이동시킨다는 의미입니다.

이를 확인하려면 git merge의 결과를 확인할 수 있습니다:

이러한 합병을 되돌리기 위해서는 main 브랜치의 HEAD를 이전 위치로 되돌리는 것만 필요합니다. 이를 위해:

  1. 이전 HEADgit reflog를 사용하여 식별합니다.
  2. 이전 HEAD로 되돌리려면 git reset --hard <previous_head> 명령을 사용하세요. 여기서 <previous_head>는 이전 HEAD로 바꿔서 입력하세요.

git reflog 명령의 출력은 다음과 같을 것입니다:

이전 HEAD를 식별하려면 “checkout: moving from feature to main”라고 나오는 줄을 확인하세요 (이는 우리의 브랜치 이름인 featuremain을 쓰기 때문에).

이 경우, 이전 헤드는 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

커밋 되돌리기 시 충돌 해결

커밋을 되돌리는 데 충돌이 발생할 수 있습니다, 특히 되돌리는 커밋이 코드베이스의 후续 변경과 충돌할 경우입니다. 이러한 경우:

  1. Git은 되돌리기를 중지합니다: 우리는 수동으로 충돌을 해결해야 합니다. Git은 충돌이 발생한 파일을 표시하고 개입을 요청합니다.
  2. 충돌을 해결합니다: 우리는 각 충돌이 발생한 파일을 엽니다, Git이 표시한 충돌을 해결하고 변경 사항을 저장합니다.
  3. 해결된 파일을 스테이지합니다: git add <file-path>
  4. 되돌리기를 계속합니다: git revert --continue

결론

git revert를 사용하여 머지 커밋을 되돌리면 커밋 기록 내의 모든 변경 사항과 수정 사항이 기록됩니다.

또한, git resetgit revert를 적절한 상황에 어떻게 적용해야 하는지 이해하면 협업 워크플로우나 로컬만의 변경 사항을 고려할 때 더 나은 결정을 내릴 수 있습니다.

이 주제에 대해 더 알고 싶다면 아래의 자주 묻는 질문(Q&A) 섹션을 읽어보세요. Git에 대해 더 배우고 싶다면 다음 자료를 추천합니다:

Source:
https://www.datacamp.com/tutorial/git-revert-merge