GitHub의 revert로 충돌이 일어났을 때

평소 GitHub의 revert는 한 번 병합하여 환경에 들어간 PR을 어떠한 이유로 제거할 때 사용합니다.



revert의 방법은 특히 어려운 이야기가 아니라고 생각합니다만, ( 과거에도 기사 로 하고 있습니다) 이번 조금 불규칙한 케이스가 일어났으므로, 비망록으로서 기사로 했습니다.

일주일 정도 전에 어떤 기능을 구현하고, 무사히 병합된 PR이 있었지만, 테스트가 따라잡지 않았기 때문에 XX일의 릴리스 대상에서 제외하고 싶기 때문에 revert해 주었으면 한다고 PM으로부터 말해진다 .

언제나처럼 revert하려고하면, 이런 오류 메시지가. . .


content may have changed since it was merged
병합되고 나서 차분이 나오니까 자동으로 revert는 무리니까요. .
실제로 이 PR이 들어가고 나서 다른 PR이 차례차례 병합되어 버린 것이 원인.

통상의 revert는 GitHub상에서 자동으로 간단하게 할 수 있습니다만, revert에 의해 컨플릭트가 발생하는 경우는 GitHub상에서는 할 수 없는 것 같습니다...

이번에는 이러한 revert에 의해 충돌이 일어났을 경우에, 충돌을 해소하면서, revert하는 방법을 소개합니다. (그 밖에도 하는 방법 여러가지 있다고 생각합니다만, 개인적으로 이것이 제일 심플하고 하기 쉽다고 생각했습니다.)

절차:



1) 먼저 Revert용으로 새로 브랜치를 자릅니다. (브랜치 이름은 revert-hoge라든지 좋아하는 것처럼)

2) 터미널에서 명령 실행
git revert <commit hash>

이 commit hash는 revert하는 PR가 병합되었을 때의 commit hash입니다.
PR 보는 것이 제일 확실.


그러면 warning 나옵니다.
error: could not revert 98b44b2e6... コミットメッセージがここに出ます (#6007)
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

3) 충돌 해결. 이것은 일반적인 충돌 해결과 완전히 동일합니다.

충돌하지 않은 파일들은 자동으로 Staging됩니다.
(revert이므로, 자신이 쓴 코드가 사라지는 역의 변경이 들어갑니다.)

4) 평소처럼 add, commit하고 원격으로 Push합니다.

5) 풀릭을 만들면 평소 GitHub에서 자동으로 만들어지는 revert PR과 같은 것이 완성입니다.

그리고는 Review 의뢰해, 병합되면 완료.

그래서 처음에는 익숙하지 않은 오류가 나와서 초조했지만 의외로 간단하게 해결할 수있었습니다.

revert 자체 평상시 그렇게 하지 않고, 이런 가끔밖에 하지 않는 것은 문서화해 두지 않으면 다음 같은 상황이 되었을 때에 곤란하기 때문에, 비망록으로서 기사로 했습니다.

좋은 웹페이지 즐겨찾기