[TIL] git rebase

이현동·2023년 1월 18일

TIL

목록 보기

8/59

문제

이번 풀 스택 프로젝트를 하면서 git을 정말 많이 사용해봤었다. 팀원 4명이서 프로젝트를 진행하면서 commit, push, pull, merge를 정말 많이 사용해봤던 것 같다. git에 꽤 익숙해질 수 있었고 자신감을 가질 수 있는 시간이었다. 그리고 좋은 팀원 분의 정리로 git-convention을 정하고 협업을 해서 commit 메세지를 깔끔하고 가독성 좋게 작성하는 연습을 해볼 수 있었다.

이번 풀스택미니프로젝트에서는 merge명령어만 사용했는데 이는 병합 완료 후, 통합 브랜치인 'main' 브랜치로 통합된 이력이 생기게 되서 commit 내역이 깔끔해 보이지 않을 수 있다.
이때 사용하는 것이 rebase 명령어인데 commit 이력이 단순해질 수 있다.

rebase

merge를 사용하지 않고 rebase를 사용하고자 했지만, 한번도 사용해본적이 없는 명령어를 팀원들이 함께하는 프로젝트에서 사용하는건 아니라고 생각돼서 일단 merge만 사용하였다.
하지만 rebase를 사용할 경우가 반드시 생길 것 같아서 정리해두려고 한다.
우선 리베이스는 브랜치의 베이스를 재설정하여 다시 커밋을 재젹용하는 작업을 의미한다.

merge와 rebase는 병합하고자 하는 목적은 같지만 특징이 다르다.

merge : 변경 내용의 이력이 모두 남아 있기 때문에 이력이 복잡
rebase : 이력은 단순해지지만, 원래의 커밋 이력이 변경됨. 정확한 이력을 남겨야 할 필요가 있을 경우에는 사용하면 안 됨

따라서 merge와 rebase는 팀의 운용 방침에 따라 구별해 쓸 수 있다.

ex

토픽 브랜치에 통합 브랜치의 최신 코드를 적용할 경우 rebase 사용

통합 브랜치에 토픽 브랜치를 불러올 경우에는 우선 rebase를 한 후 merge

rebase 방법

git checkout feature
git rebase master
git checkout master
git merge feature : 한 줄이 되었기 때문에 빨리 감기 병합을 수행한다.

rebase로 특정 시점 commit 히스토리 조정

이 과정은 커밋 히스토리를 조정하는 기능이다. 기능을 개발하는 중에 사소한 부분을 여러면 커밋한 적이 있다면 이 커밋을 큰 하나의 커밋으로 변경을 할 수 있다. 때로는 간단한 문구 수정이나, 줄 간격 맞추기 등도 수정을 한 후 커밋을 하게 되기 때문에, 이때에도 rebase가 사용될 수 있다.
1. git rebase -i HEAD~n : 지우고 싶은 커밋이 보이는 곳 까지(n) 이동
2. 에디터 실행

pick 44d0f0c new feature: Add add feature function.
squash 85dd2a2 order: Fix add function error.
reword 6411bf5 order: Add update function.

합치고 싶은 commit은 pick
pick으로 합치고 싶은 commit은 squash
내용을 수정하고 싶은 commit은 reword

이때 가능하면 push하지 않은 작업만 squash하는 것이 좋다. pushdhk pull 작업이 살짝 어려워질 수 있음.

rebase 규칙

리베이스와 관련된 자주 발생되는 이슈들을 피하기 위해서는 다음과 같은 규칙을 지키는 편이 좋다.

원격 저장소에 올라간 커밋은 리베이스 하지 말 것.
왜냐하면 예를 들어 C1 커밋을 원격에 push하고 rebase를 하게 되면 원격에는 C1이 존재하고 로컬에는 다른 커밋인 C1'가 형성되어 동일한 커밋의 사본이 여러개 존재하게 된다.
다만, 혼자 작업을 하는 깃이면 상관없다. 안전하게 force push 할 수 있기 때문이다.
리베이스 전에 리베이스 하려는 브랜치 끝에서 백업 브랜치를 만들어 놓자.
이는 리베이스 후 결과물을 쉽게 비교할 수 있게 해주고 필요 시 리베이스 전 상태로 돌아갈 수 있게 해준다.
혼자 또는 작은 규모의 팀에서는 리베이스를 사용하는 편이 좋고, 큰 규모의 팀에서는 머지를 사용하는 것이 좋다. 하지만 이 역시 정답은 아니다.