git rebase 중 conflict 해결 (반)성공기

지난번 git rebase conflict 실패기의 해결 방법을 알아왔다! 이번 포스팅은 아래와 같은 포스팅을 참고하면 더 재미있게 읽을 수 있고, 히스토리를 몰라도 이해하는데에는 불편함 없으리라 예상된다.

https://yuniel.tistory.com/53

git rebase 중 conflict 해결 실패기

이 시간들이 쌓여 언젠간 고수가 되어있을 그 날을 그리며...

 

---

이번에는 master 브랜치와 rbConflictTest 브랜치로 진행해보도록한다. 현 상황은 master과 rbConflictTest 브랜치에 있는 커밋이 100% 똑같은 상황이다.

 

이 상황에서 rebase의 기본 조건을 충족시키기 위해 master에 몇 개의 commit을 더 추가한다.

master branch

이제 rbConflictTest 브랜치로 가서 같은 파일 동일 부분에 수정을 하여 commit-push 할 것이다.

rbConflictTest branch

git checkout rbConflictTest // 현 브랜치와 동일 브랜치로 생략
git rebase master

를 실행하면

먼저 커밋을 한 rbConflictTest - git rebase conflict test A에 대한 겹친 부분이 conflict로 뜨게된다.

충돌을 해결하여 push를 하려고 하면 저번과 같은 Git: Terminal is dumb, but EDITOR unset이라는 경고가 뜨게된다. 그럼 마찬가지로 rebase를 계속 진행하라는 git rebase --continue를 실행시켜준다.

git rebase --continue

그러면 지난번 막혔던 부분과 동일한 다음과 같은 현상이 나타난다.

해당 형식과 같은 에디터는 평소 강의를 들으면서 종종 봐왔는데, 이 에디터는 VIM이라고 불리는 에디터라고 한다.

Vim은 Bram Moolenaar가 만든 vi 호환 텍스트 편집기이다. CUI용 Vim과 GUI용 gVim이 있다. 본래 아미가 컴퓨터 용 프로그램이었으나 현재는 마이크로소프트 윈도우, 리눅스, 맥 오에스 텐을 비롯한 여러 환경을 지원한다.

- 위키백과

자세한 사항은 기회가 되면 알아보도록 하고, 일단 나는 이 부분에서 막혀 실패했었는데 해결 방법을 공유해보도록 하겠다.

 

우선 나는 commit message를 수정하지 않고, 그대로 push 할 예정이기 때문에 i를 눌러 vim의 insert 모드로 진입해준다. 그 후, 제일 첫번째 줄에 pick 이라는 명령어를 적어준다.

pick 커밋 메세지

해당 명령어를 저장 및 에디터를 나가기 위해 esc키를 눌러 insert 모드를 나간 후, :wq라는 명령어를 작성한다.

 

그럼 다음 충돌 커밋인

test B의 커밋으로 넘어오게 되고, 상단과 같은 vim 진입을 진행한다. 이번에 나는 커밋 메세지를 수정해보는 예시를 진행해보려한다.

reword 커밋 메세지

그럼 이렇게

rbConflictTest 브랜치에는 rebase가 되어 master에서 새로이 추가한 commit 메세지 위에 내가 수정한 메세지가 올라간다. 근데 pick과 reword는 명령어인줄 알았는데, 이렇게 브랜치 vs 브랜치의 rebase 충돌 과정에서는 먹히지 않는 것 같다. 그대로 commit 이름이 올라간 것 보니까 ^0^............

 

아무튼 이 상태로 push를 하려고 하니 pull이 이미 있다고 에러가 발생한다.

 

또 이유는 전혀 알 수 없는 Git: You have not concluded your merge (MERGE_HEAD exists) 에러와 함께

잘 한다고 했는데, 아마 merge 과정에서 또 문제가 있는듯하다 ㅠㅠ 제발..

 

일단 머지 과정을 취소해준다.

git merge --abort

그런다음

git status

통하여 충돌 부분을 정리하여준다.

한국말인데 또 무슨말인지 이해할 수 없다. 커밋 사항이 없고 작업 폴더가 깨끗한건 아닌가.... 아무튼 해결할 merge 사항이 없는듯 하여, 저 메세지 말에 맞게 git pull을 실행한다.

그럼 얘가 또 뭐라고 한다 ^.^.....

 

---

 

결론적으로 말하면

 

로 commit 순서가 정렬되어 push가 되긴 되었다.

 

씨름을 하느라 캡쳐한 부분이 없어 깔끔하게 후기를 남기지는 못 하겠지만 혹시 나와같이 멘붕인 분들을 위하여 해결 방법을 횡설수설 말해보자면

 

나와같은 경우에는 git merge --abort를 실행한 후, git pull을 하면 새롭게 merge 할 부분이 나타나긴 했다. 그런데 뭐랄까 예를들어

// current
console.log('A');
console.log('B');
console.log('c');
console.log('D');
// incomming
console.log('C');
console.log('D');

다음과 같이 떴을 때, 나는 C와 D의 중복을 피하기 위하여 accept current를 수행하였고, 그럼 현재 파일과 같아지기 때문에 merge를 위해 push 할 파일이 없어졌다. 그러면서 다시 merge가 진행중이라는 무한루프에 빠지게 된 것이다.

 

그래서 꼼수를 써서 accept both를 수행한 뒤, 중복되는 C와 D 두 줄을 삭제한 후 저장을 하였다.

 

결과적으로 같은 라인에 같은 문구만 남았는데, 이는 merge를 위해 push 할 파일이 남아있다고 인식하였고 무사히 push를 하여 다음 스텝을 진행할 수 있게 되었다.

 

사실 해결 방법이 명확하지 않아 매우 찝찝하지만 ... 일단 rebase의 굴레에서 벗어나고 싶어.... 반은 성공이라고 위안해본다.