Git Rebase 이해하기

soleil_lucy·2024년 8월 18일
1

git

목록 보기
2/2
post-thumbnail

강의를 듣다가 git rebase에 대해 알게 됐습니다. 지금까지 git rebase 명령어 없이 프로젝트를 관리했던 사람이어서 해당 명령어가 궁금해졌습니다. 그래서 git rebase에 대해 알아보고자 이 글을 작성하게 됐습니다.

Git Rebase란?

Git에서 브랜치를 병합하는 방법에는 두 가지 주요 방법이 있습니다. MergeRebase 입니다. 이 중 Rebase에 대해 알아보려고 합니다.

Rebase의 기본 개념

Git Rebase는 현재 작업 중인 브랜치의 커밋을 다른 브랜치의 최신 커밋 뒤에 이어 붙이는 방식으로 병합하는 명령어입니다. 이 과정을 통해 마치 해당 브랜치가 처음부터 최신 브랜치에서 시작된 것처럼 보이게 됩니다. 예를 들어, feature 브랜치에서 작업 중인데, main 브랜치에서 새로운 업데이트가 있을 경우, git rebase main 명령을 실행하면 feature 브랜치의 커밋들이 main 브랜치의 최신 커밋 뒤에 이어붙여집니다.

이 과정을 통해 히스토리가 직선으로 정리되어, 프로젝트의 변형 과정을 쉽게 추적할 수 있습니다.

Rebase를 사용하는 이유

Git Rebase의 주요 목적은 프로젝트의 히스토리를 선형으로 유지하는 것입니다. git merge와 달리 git rebase는 merge commit을 생성하지 않기 때문에 히스토리가 깔끔하게 유지됩니다.

Rebase를 사용하는 주된 이유:

  • 선형적인 프로젝트 기록 유지: Rebase를 사용하면 커밋 기록이 단순하게 정리됩니다. 모든 커밋이 하나의 브랜치에서 순차적으로 일어난 것처럼 보이기 때문에, 커밋 히스토리를 더 쉽게 이해할 수 있습니다.
  • 변경 사항의 명확한 이해: 프로젝트의 히스토리가 직관적으로 정리되어 있으면, 디버깅을 하거나 문제를 해결할 때 큰 도움이 됩니다. 어떤 변경 사항이 언제, 왜 발생했는지를 쉽게 파악할 수 있습니다.

Rebase의 위험성

하지만 Git Rebase를 사용할 때는 주의가 필요합니다. 특히, 리모트 리포지토리(다른 사람과 공유되는 중앙 저장소)에 이미 푸시된 커밋을 Rebase하는 것은 위험할 수 있습니다.

리모트 리포지토리에 이미 푸시된 커밋을 Rebase하면 안되는 이유:

  • 커밋의 재작성: Rebase는 기존 커밋을 새로운 커밋으로 대체합니다. 이로 인해 다른 사람들이 이미 가져간 커밋과 충돌이 발생할 수 있으며, 프로젝트 기록의 일부가 사라진 것처럼 보일 수 있습니다.
  • 협업 문제 발생: 협업 중인 다른 개발자들이 이미 해당 커밋을 기반으로 작업을 진행하고 있을 수 있습니다. 이때 리모트 커밋을 Rebase하면 협업에 큰 혼란을 초래할 수 있습니다. 이는 코드 충돌이나 예상치 못한 버그를 유발할 수 있습니다.

따라서 rebase는 로컬 브랜치에서만 사용하는 것이 안전합니다.

Git Rebase와 Git Merge

앞서 Git에서 브랜치를 병합하는 방법에는 두 가지 주요 방법으로 git rebasegit merge를 소개했습니다. 이 두 가지 명령은 어떻게 다른지 살펴보겠습니다.

Git Rebase와 Merge의 차이점

git merge는 리포지토리의 전체 기록을 보존하며 브랜치를 통합하는 안전한 방법입니다.
git merge

반면, git rebase는 기능 브랜치를 다른 브랜치의 최신 커밋 위로 이동시켜서 선형적인 히스토리를 만드는 방법입니다.
git rebase

그렇다면 두 방법 중 어느 것을 선택해야 할까요? 이 질문에 답하기 전에 히스토리의 의미를 다시 살펴보겠습니다.

히스토리의 의미

  • 작업 내용의 기록: 히스토리는 작업 내용을 기록한 문서이며, 각 기록은 고유한 의미를 가지고 있습니다. 변경할 수 없는 기록을 다루는 것은 역사를 왜곡하는 것과 같습니다. 많은 merge 커밋이 쌓이면 히스토리가 지저분해질 수 있지만, 이는 프로젝트의 실제 진행 상황을 반영하기위해 보존해야 한다.
  • 프로젝트 진행의 이야기: 소프트웨어 개발의 히스토리를 매끄럽게 다듬고 싶을 때, rebasefilter-branch와 같은 도구를 사용할 수 있습니다. 이렇게 하면 프로젝트의 진행 과정을 더 깔끔하고 이해하기 쉽게 정리할 수 있습니다.

그래서 Rebase와 Merge, 어느 것을 선택해야 할까요?

Git은 강력한 도구로, 상황에 맞게 다양한 기능을 제공합니다. 각 팀과 프로젝트는 다르기 때문에 rebasemerge의 사용 방법도 상황에 따라 달라질 수 있습니다.

일반적으로, local branch에서 작업할 때는 히스토리를 깔끔하게 유지하기 위해 rebase를 사용하는 것이 좋습니다. 그러나 remote branch에서 공유된 커밋은 rebase를 사용하지 않는 것이 안전합니다. 이미 푸시된 커밋을 rebase하면 다른 사람들의 작업과 충돌이 생길 수 있으며, 협업에 혼란을 줄 수 있기 때문입니다.

결론적으로, 각 상황에 맞게 적절한 도구를 선택하여 히스토리를 관리하는 것이 중요합니다.

새로 알게된 점

  • Git에서 브랜치를 병합하는 방법에는 두 가지 주요 방법이 있습니다. 바로 MergeRebase이다.
  • git merge 명령어는 리포지토리의 전체 기록을 보존하면서 브랜치를 안전하게 통합합니다.
  • git rebase 명령어는 기능 브랜치를 다른 브랜치의 최신 커밋 위로 이동시켜, 선형적인 히스토리를 만듭니다.
  • 브랜치를 병합할 때, 히스토리의 의미로 결정을 내린다면, 모든 작업 내용을 기록으로 남기고 싶다면 merge를 사용하고, 프로젝트 히스토리를 선형으로 정리하고 싶다면 rebase를 선택할 수 있습니다.
  • 주의할 점으로 rebase는 절대로 절대로 리모트 리포지토리에 푸시한 커밋에는 사용하지 말아야 합니다.

히스토리 내역을 선형으로 관리하고 싶다면 rebase를 적절하게 사용하면 유용할 것 같습니다. 그러나 아직 실제 사용 경험이 부족하여 감이 잡히지 않습니다. 따라서, 실습을 통해 익숙해져야 할 것 같습니다. 현재는 더 익숙하고 안전하다고 느끼는 merge를 사용하여 프로젝트를 관리하려고 합니다. rebase는 좀 더 연습하고 원격 리포지토리를 건드리지 않고 사용하는 방법에 익숙해지면 그 때 사용해 보려 합니다.

참고자료

profile
책을 좋아하는 개발자입니다.

0개의 댓글