Portfolio

🔍 문제 및 궁금증

미란 누나와의 눈물의 우당탕탕 깃 대작전 이후 (...) 한 번 이를 공식 문서화하여 다시는 실수 안 하기로 다짐하였다.

💡

우리... 다시는 깃으로 밤새우지 말자...!!! 😥😥😥

우리가 해결한 방법은 다음과 같았다.

일단 멋지게 리베이스를 하려고 하였으나, 계속 아무리 고쳐도 needs merge가 뜨는 바람에 실패.

그 이유는 아무래도, 기존 데이터와의 충돌이 계속해서 발생했기 때문이라고 생각했다.

무엇보다 변경할 사항이 많지 않았다.

따라서 과감히 git reset--hard [커밋 번호]를 통해서 기존 분기 이전으로 되돌린 다음, 과감히 rebase upstream/develop을 실시, 다시 같은 베이스에서 작업을 해주도록 했다.

💡

하지만 이렇게 하지 않아도 됐었을 일이었고, 나도 같은 일을 겪을 수 있다는 생각이 들었다. 이 글은 이를 해결하기 위한 글이다.

📢 해결 방법

#1. 먼저 기존 데이터를 다 불러오자!

fetch와 pull이 있겠는데,

fetch의 경우 데이터만 불러오는 기능을 하며

pull의 경우 fetch와 merge를 합한 기능이라고 생각하면 되시겠다. (즉, 충돌이 나시겠지?!)

우리는 일단, fetch로 데이터를 가져와 맛만 보자!

💡

항상 get l --all 해주는 센스! 잊지 말자구~

#2. 머지를 했다?! 그렇다면 일단 우리는 가지치기를 하자.

더이상 원격 브랜치를 갖고 있을 이유가 없다. 없애주자.

💡

가지치기를 하는 명령어는? git remote prune upstream

#2. 그렇다면 우리가 해야 할 일은?

먼저 기존 작업들을 임시 저장을 해주자. 이는, 이동하기 편하도록 하기 위해서이다.

💡

git stash

그 다음을 살펴 보자.

호오, 원격과 로컬의 develop이 다르다. 이런 상태에서 작업을 할 시, 깃 모양이 이쁘지 않을 것이다. 따라서 나는 이를 한 리베이스로 묶어서 작업을 해줄 것이다.

💡

기존 작업들은 stash했기 때문에 나는 마음껏 움직일 수 있다! pop만 유념하자구~

#3. 그럼 낙동강 오리알인 작업 중 브랜치는?

얘도 다시 리베이스를 해주면 된다. 핵심은 같은 베이스 상에 놓게 해주는 것이 우리 깃 전략에 핵심이다. 따라서 rebase를 해주자.

💡

git rebase upstream [MGC-OO]

#4. 아직 안 끝났어! 기존 작업물 반영해야지~

아참! 아직 임시 저장을 안 풀어줬다. 그럼 이제 pop만 하면 해결 끝~

💡

git stash pop

마치며

그렇게 아닌 새벽에 눈물의 깃 해결이 끝났다.

이것은 눈물을 희생시켜 만든 산물이다. 이제 해...해치웠겠지...?

💡

행복... 행복하자... 행복하자... 우리...

아프지 말고... 깃 때문에 아프지 말고... 따흑...😂

참고자료

깃 대마왕 민철의 깃 병법 제 2장 3절에서 발췌

Git merge 후 우리가 해야 할 일