git branch 상에서 작업을 마치고 나서 merge 명령어를 통한 merge 작업은 그 이력이 누적되게 되면 merge-commits들이 쌓이게 되어 프로젝트가 오래 진행 될 수록 그 이력이 복잡해지기 쉽다.
위와 같은 문제를 해결하고자 git rebase, squash 개념을 사용하면 정말 필요한 이력 및 commit만 남기고 좀 더 알기 쉽고 유지보수가 용이하게 git log를 관리할 수 있다.
실제 프로젝트를 진행하면서 rebase를 진행했던 절차는 다음과 같았다.
(브랜치에서 작업 도중 master 브랜치를 최신화 해야 할 때)
$ git checkout origin master
$ git pull origin master
(여기서 작업중인 브랜치로 merge를 진행하는 것이 아닌 rebase를 진행한다고 보면 된다)
$ git rebase -i master(master로 부터 rebase로 정리한다)i 옵션에 의해 각각에 경우에 commit 에 대해 pick과 s(squash)로 구성되어 있다 맨 위의 가장 앞서는 commit을 중심으로 하나의 commit으로 합쳐 하나의 commit으로 만들 생각이다.(그렇지 않고 중간의 commit이나 그 다음 부터 하면 이전 commit이 무시되어 그 이력이 소실된다)
pick은 commit을 한 순서대로 되어 있으며 보통 squash는 가장 앞서는 commit을 기준으로 합친다 생각하고 진행한다 (rebase 후 실제 commit 메세지는 rebase 다음 단계에서 충분히 수정 가능하기에 rebase 단계에서 사라지는 commit 메세지에 연연할 필요가 없다)
rebase 조정을 끝내주면 conflict가 일어나거나 commit 메세지를 입력하라는 text 들이 뜨게 되는데
conflict는 이전에 merge 관련 이벤트를 처리 해 주었던 것 처럼 처리해 주고
$ git add .
$ git rebase --continue등을 진행하면 해결이 된다. conflict가 없다면 git rebase --continue 과정을 진행하지 않고 commit 메세지 수정 후 바로 rebase과정이 마무리 되게 된다.
이제 rebase과정을 통해 수정된 commit을 remote 저장소에 push를 하려고 하면 에러가 나게 된다. 이유는 rebase sqaush 등을 통해 여러개의 이력이 되었던 commit을 인위적으로 합치는 과정을 거쳐 git history를 수정했기 때문이다. 하지만 실질적으로 master branch에 필요한 것은 작업이 완전히 끝나고 수정도 마무리 된 하나의 commit이 의미가 있다. 자잘한 수정 과정 내용이 들어간 commit이 많이 들어가게 되면 실제로 프로젝트 이력관리가 복잡해지고 정리가 잘 안될 수도 있다.
각설하고 인위적으로 history가 수정된 상태인 branch에 대해 --force옵션을 더하면 remote 저장소에 원하는 branch를 무사히 반영할 수 있게 된다.
$ git push origin <my_branch_name> --force이렇게 프로젝트를 관리하게 되면 아래와 같이 이상적인 branch의 형태로 유지보수가 용이하게 프로젝트를 관리할 수 있을 것이다.
(이미지 출처 : https://jasonmccreary.me)
