<git 00탄 REBASE vs. MERGE >

강민수·2022년 1월 1일
0

무지성 시리즈

목록 보기
2/7

00. intro

지난 시간에는 깃 머지 시에 필자의 무지성이 불러일으킨 에러를 보셨을 것이다. 이번 시간에는 그때 무지성이어서 알지 못 했던 리베이스와 머지에 대해 알아보고, 다시 둘 간의 어떤 차이가 있는 지 알아보고자 한다.

01. Rebase?

리 베이스라는 말은 결국, 뭔가를 다시 설정하는 것을 의미한다. 필자는 이 컴퓨터 용어들도 역시 누군가가 원래 있던 단어들을 활용해서 적합한 상황에 맞춰서 네이밍하는 것이라고 생각한다. 이번에 살펴볼 리베이스 역시 알고보니 일맥상통한 의미였다.

자! 각설하고, 이제 리베이스가 뭔지 다시 봅시다.

rebase: 리베이스는 베이스 되는 지점을 바꾸는 것을 의미한다. 즉, 깃은 버전 관리를 하면서 어쩔 수 없이 커밋을 남기게 되고 그것을 푸쉬하게 된다. 이에 따라 깃 허브 상에서 브랜치에 커밋한 내역이 남게 된다. 그런데 이런 기존의 커밋 히스토리를 바꿔주는 것이다.

자 다음의 그림을 보자.

흔히 우리가 기존의 베이스가 되는 지점에서 피쳐 브랜치를 따서 작업후 머지하는 과정을 거치는 리베이스 하기 전의 깃의 구조도다.

아래와 비교해 보자.

차이가 보이시는 가? 그렇다. 기존의 베이스에서 피처를 따서 작업한 피쳐 브랜치가 사라지고, 마스터에서 피처를 따서 작업한 것으로 내역이 바뀐 것을 확인할 수 있다. 이처럼 리베이스는 깃의 역사를 바꾸는 것이라고 할 수 있다.

02. 그렇다면 왜 사용하는 것이고, 언제 사용하는 것이 좋은가?

Commit history를 깔끔하게 관리하기 위해 사용한다. rebase를 사용하여 커밋을 편집할 수 있기 때문이다.Merge Commit이 생성되지 않고, 직관적인 History로 프로젝트를 관리 할 수 있다. 규모가 큰 프로젝트의 경우 직관적인 History는 버그 픽스, 유지 보수 측면에서 더 효율적이라 할 수 있다.

즉, 무수히 많은 커밋을 하다보면 이게 무슨 커밋이었는지 기억이 안 날때도 있고, 초기 셋팅 시에 불필요한 커밋을 많이 하게 되어 있다. 그럴때 마다 머지를 하면 모든 커밋의 기록은 남게 된다. 그래서 리베이스를 통해 불필요한 커밋을 단절시키고 이제부터 새롭게 커밋의 기록을 남겨서 필요한 것들만 딱 알자배기로 남기자는 것이 리베이스라고 보면 좋을 것 같다.

03. 리베이스와 머지의 차이

사실상 그러다보니, 머지를 써야 하는 지, 리베이스를 써야 하는 지에 대해서 개발자들 간의 갑론을박이 아직도 많은 것이 실정이다. 하지만, 분명한 것은 어느 것이 더 낫다거나 좋다는 것은 없다.

다만 보편적으로 히스토리를 보는 관점의 차이가 가장 큰 것이 머지와 리베이스의 차이라고 생각해 보면 좋다.

그래서 대개는 머지는 개인 레포에서 작업할 경우 보편적으로 많이 사용하고, 물론 이역시 팀마다 협의해서 리베이스를 사용할 수도 있다. 그러나 대부분은 머지를 쓴다. 그 이유에 대해서는 다음의 필자가 충돌한 경험을 빗대어서 설명해 보겠다.

04. 리베이스 사용의 주의사항 및 필자의 문제점 연결

rebase 시 유의사항

  • 이전의 커밋 히스토리를 변경하기 때문에 항상 주의가 필요합니다.

  • 만약 이미 Github과 같은 원격 저장소에 push까지 한 커밋이라면, 변경한 커밋들은 원격 저장소에 push 되지 않을 것입니다.

  • 이때 $git push --force, $git push -f 명령으로 강제로 원격 저장소에 커밋 히스토리를 덮어쓸 수 있습니다.

  • 만약 이전에 push 한 커밋들을 다른 개발자들과 공유하고 있었다면, 커밋 히스토리의 불일치가 발생해 git이 꼬이는 현상이 발생할 수 있습니다.

    필자는 팀단위 초기셋팅이후, 풀이 안되길래... 리베이스를 진행했다. 그런데 기존 작업물들에 대해 푸쉬한 커밋이 존재했었다. 그것도 모른 채 무작정 리베이스 하고 풀을 한 뒤에 다시 푸쉬를 하려니...

    이런 푸쉬 오류를 만날 수밖에 없었다. 그 이유를 이해해 보니, 이제야 이해가 간다. 즉, 이전의 커밋한 작업이 푸쉬 되어 있는 저장소와 지금 리베이스 한 저장소의 커밋이 일치하지 않기 때문에 깃허브 측에서 거부를 해 버린 경우다.

    따라서 필자는 강제로 커밋 히스토리를 덮어 씌워서 겨우 해결은 했다.

    만약, 이미 개발 진척이 많이 된 상태였다면 상상도 하기 싫다.. 따라서 팀 프로젝트에서 팀원들 간의 협의 과정 없이 함부로 리베이스 하는 것은 주의가 정말 필요하다는 생각이 들었다. 왜냐면 저 주의사항처럼 깃 커밋 히스토리가 불일치하기때문이다. 그렇게 되면 잘못하면 나 혼자만의 리베이스로 팀원 전체가 리베이스를 하는 불 상사가 발생하고 기존 커밋 내역이 다 날라갈 것이다.

아직 끝없는 샘물같은 깃이다. 이후에도 계속 수많은 고난과 부딪쳐보면서 마주하고 그때마다 기록해야겠다.

profile
개발도 예능처럼 재미지게~

0개의 댓글