Git을 사용하다보면 가끔 오류를 마주하곤 하는데요, 역시나 혼자 해결못했지만🥲 이번에는 돌이켜보며 뭐가 문젠지 알아버려야겠다는 집념으로 작성한! 제가 마주한 오류과 원인, 해결방법에 대한 글입니다. :)

💣 문제 발생

상황은 이러합니다. 고구마와 감자가 함께 작업중입니다.
1. 고구마 Push
2. 감자 MR (메인브런치와 병합 전)
3. 감자의 Merged 후, 고구마는 pull > rebase > 충돌해결 > push
4. 오류 발생

! [rejected]        <branch-name> -> <branch-name> (non-fast-forward)
error: failed to push some refs to '...'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

🔍 문제 원인

진정하고 원인을 알아봅시다. rebase의 특징과 merge와의 차이를 찾아봅니다.

Rebase와 Merge의 차이

다음과 같은 commit 히스토리가 있는 상황에서 비교해봅시다.
feature 브랜치에서 master 브랜치로 rebase/merge를 실행한 예시입니다.

A - B - C (master)
     \
      D - E - F (feature)

리베이스(Rebase)

A - B - C - D' - E' - F' (feature)

• 한 브런치 변경 사항을 다른 브랜치의 커밋 위로 재적용하면서 커밋 ID가 변경됩니다. (D, E, F > D', E', F')
• 커밋 히스토리가 깔끔해지지만, 이미 푸시된 커밋을 다시 작성하는 경우 강제 푸시가 필요할 수 있습니다.

병합(Merge)

A - B - C - M (master)
      \    / 
       D - E - F (feature)

• 두 브런치 합칠 때 새로운 커밋을 생성하여 변경 사항을 통합합니다. (기존에 없던 M 커밋 생성)
• 커밋 히스토리가 분기된 상태로 남아있습니다.

고구마가 리베이스를 수행하면서 발생한 문제

1. 고구마의 rebase 사용으로, 고구마의 커밋들이 메인브런치에서 재작성되어 기존 커밋 ID가 변경됩니다.
2. 원격저장소에 고구마가 이전에 push한 커밋 ID와 rebase한 이후 커밋 ID가 불일치합니다.
3. 히스토리 불일치로 "non-fast-forward" 오류가 발생합니다.
   : 원격 브런치의 커밋이 로컬 브랜치의 커밋과 충돌한다는 의미

Rebase를 사용해서 그런것이었습니다...!!!!!!(그럴줄알았다)🤦🏻‍♀️

---

💡 문제 해결!

이 문제를 해결하기 위한 두가지 방법이 있습니다.

1. Force Push

로컬 브런치의 커밋 히스토리를 원격 브랜치의 히스토리에 강제로 적용합니다.

$ git push --force

유의사항

• 원격 저장소의 기존 커밋 히스토리를 덮어쓰기 때문에 다른 개발자들과 같은 브런치에서 작업시 충돌이 발생할 수 있습니다.

2. Cherry-Pick 🍒

Cherry Picking ?

케이크 위에 얹어져 있는 체리만 집어먹는 행위로 "자신이 정확하게 원하는 부분만 취하는 행위"를 뜻한다고 합니다.

Git에 적용하면, 다른 branch에 있는 많은 commit중 원하는 commit만 쏙 가져오기인거죠!

$ git cherry-pick <commitID 혹은 commitID 앞 여섯자리> <commit2> ... <commit5>

• 커밋 히스토리를 재작성하지 않으므로, 기존 히스토리를 유지하면서 필요한 변경 사항만 적용할 수 있습니다.

유의사항

• 커밋이 옮겨지는게 아닌, 새로운 커밋이 늘어납니다.
• 커밋 히스토리가 복잡해질 수 있습니다. (동일한 커밋이 여러개의 브런치에 존재, 충돌 해결과정에서 커밋 추가 가능성 등)
• 커밋을 가져오는 과정에서 동일하게 충돌이 일어날 수 있습니다.

---

그래서 고구마는요 ..

1. 새브런치 생성 (감자의 MR이 반영되어있음)
2. cherry-pick으로 고구마의 commit 내역 가져오기
3. 충돌잡기
4. push
5. 이전 브런치 삭제

이렇게 해결했답니다 🤗

---

💬 마무리

최근 아티클에서 Rebase와 Merge의 차이를 올렸었는데, 이번 블로그 작성으로 더 정확하게 이해하게 되었습니다..! Rebase를 사용하라는 전 팀장님의 지시가 있었어서 git을 시작할 때부터 자연스럽게 Rebase하는 습관을 들였는데 이제는 차이를 알고 사용할 수 있게 되었습니다!(알아버려서 Merge만 쓸듯..) '왜 나는 오류가 자주 뜨는거지?'라는 생각을 했었는데, 그야 Rebase만 쓰니까.. 커밋 ID가 바뀌어 버리는 특징 때문이었다는것..

개인적인 의견이지만 Rebase는 커밋 히스토리만 깔끔하게 해줄 뿐 크게 장점이 없는것같습니다. 오히려 커밋 히스토리가 다 남게되는 Merge를 쓰면서 커밋 메세지를 더 구체적으로 작성해야겠다는 생각을 했습니다. 오류가 나도 아무렇지않게 해결해버리는 그날까지..! 화이깃

---

참고 및 출처
https://dongminyoon.tistory.com/9
https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-%EC%9B%90%ED%95%98%EB%8A%94-commit-%EA%B0%80%EC%A0%B8%EC%98%A4%EA%B8%B0-cherry-pick
https://velog.io/@juhyeon1114/Git-Cherry-pick