Commit History의 중요성? Git Rebase 알아가기!
intro 프로젝트를 할 때 에러가 발생하여 이전 커밋으로 돌아가야 하는 상황이 생겼었다. 그러나 너무 많은 브랜치로 인한 복잡해진 Git History는 나를 당황시키기 충분했다... 이후 많은 분들이 rebase를 사용하신다는 말을 듣게 되었고 궁금증이 생겨 블로깅을 하게 되었다.
What is Git rebase?
Rebase is an action in Git that allows you to rewrite commits from one Git branch to another branch. Essentially, Git rebase is deleting commits from one branch and adding them to another.
Rebase는 Git의 액션으로, 한 Git 지점에서 다른 지점으로 커밋을 다시 작성할 수 있도록 허락한다. 기본적으로, Git rebase는 한 브랜치에서 커밋을 삭제하고 다른 브랜치에 그것들을 추가한다.
rebase는 base를 재설정한다라는 의미처럼 작업 중이던 feature 브랜치를 main 브랜치에 결합하는 방식이다. 때문에 하나의 브랜치에서 작업한 것처럼 보인다는 특징이 있다.
왜 rebase를 사용하는 걸까?
이렇게 작업하면 Git History가 깔끔해지기 때문에 작업자가 보기에도 혹은 다른 개발자가 보기에도 편하다는 것이 가장 큰 장점이 아닐까 싶다. 프로젝트를 할 때, 특히 인원이 많을수록 많은 브랜치를 만들어서 작업하고 병합하다 보면 마치 서울 지하철처럼 아주 복잡해지는 경우가 생기고 만약 어느 부분에서 에러라도 발생하게 된다면 이전 커밋을 찾기 어려워질 우려가 있다... 그렇다 나의 이야기이다.😅
백엔드와 프론트엔드가 함께한 프로젝트였는데 다 같이 열심히 merge만 하다 보니 오색빛깔 History가 완성되었다... 이처럼 merge는 모든 커밋 흔적이 유지된다. 즉, 병합을 하더라도 커밋 메시지가 중복으로 쌓인다는 특징이 있다. 그래서 보통 rebase → push → PR → merge 순으로 진행하신다는 것을 알게 되었다.
이외에도 공유 branch의 변경사항을 즉각적으로 반영할 수 있다는 장점이 있다고 한다.
Rebase는 언제 사용할까?
Rebase는 커밋 시간에 관계없이 merge 되는 브랜치의 가장 뒤에 붙는 전략이기 때문에 push 하기 전까지만 사용해야 한다. 이는 rebase 하기 이전의 커밋 버전과 이후의 커밋 버전이 다르기 때문에 충돌이 발생한다.
때문에 rebase는 주로 '내가 작업하던 브랜치에 변경된 main 브랜치 내용이 필요할 때' 사용한다.
주의점도 알아두자!
- main 브랜치를 rebase 하는 행위는 피하자! (가지가 꼬인다...)
- 서로 다른 브랜치 간에 공통된 파일 혹은 수정 내역이 없어야 충돌이 일어나지 않는다.
이번 글을 작성하며 사소한 것이라 생각했던 Commit History 관리의 중요성을 많이 느꼈다. 프로젝트가 끝나고 나서야 왜 rebase를 사용하는지 이해할 수 있었다.
📜 출처