오늘 살펴볼 것은 git rebase이다.
Git Flow
그동안의 나의 Git flow는 다음과 같았다.
push -> PR작성 -> merge -> pull
main 브랜치에서 feature 브랜치를 따 작업을 하고 작업 내용을 Push 및 PR작성 후에 main에 곧바로 merge 시킨다. 이 변경사항을 pull받아 업데이트 시킨다.
실제 개발 환경에서의 Git Flow는 이보다 몇 단계의 레이어가 더 존재한다.
위 그림에서는 feature/develop/main 크게 세 가지 종류의 브랜치가 존재한다.
feature는 이전과 같이 어떤 하나의 소작업을 하는 브랜치로 사용된다.
develop은 feature에서 작업했던 내용이 하나로 합쳐지는 구간인데, 지금까지의 flow에서 main으로 사용해 왔던 브랜치는 사실상 develop 브랜치와 다름 없다.
이 develop 브랜치는 스테이징 단계라고도 하는데 스테이징 단계에서 배포할 준비가 되었다면 release 브랜치를 파서 QA를 진행한다.(현업에서는 stage 브랜치가 따로 있는 경우가 많음.) 여기서 버그가 발생하면 이 브랜치에서 바로 수정을 한다. 수정 사항은 역시 develop이나 feature 브랜치에 pull 시킨다.
버그까지 수정이 되었다면 main에 merge한다. 배포 후에 급하게 수정해야 할 버그가 발생한다면 hotfix브랜치를 파서 수정한 후 main에 merge 한다. 이 변경사항들은 나머지 브랜치에 pull받아 업데이트 시킨다.
Git rebase
장점: 불필요한 머지커밋이 생기지 않음
브랜치 생성시 기준이 되는 브랜치의 마지막 커밋: base
e.g., main에서 브랜치 하나 파면 그 브랜치의 마지막 커밋까지 들고들어감
rebase: 기준이 되는 브랜치의 마지막 커밋이 있는 그 시점에 브랜치를 새로 판척을 한다. 같은 작업끼리 모으기 위해! 머지는 중간중간 들어가지만..
squash
커밋을 하나로 최적화시키는 것
rebase rule
다음은 절대적인 법은 아니지만 지키면 좋은 rebase rule이다.
- rebase 전 commit을 네개 이상하지 말자.(충돌 해결 시 복잡하니까)
- 커밋이 2~3개 쌓이면 rebase를 진행하자. (rebase할 필요가 없어도 스쿼시 목적으로라도 리베이스 ㄱㄱ)
- 가장 위에꺼만 pick으로 두고 나머지는 s로 두자
- 충돌이 일어난 경우 충돌 해결 후 git add. -> git rebase --continue
- 해결이 안되면 git rebase --abort
Rebase 하는 법
- 메인에서 git pull
- 작업한 브랜치가서 git rebase -i main (i는 interactive. interactive 쉘이 열리면서 리베이스). (git rebase -i 베이스 삼을 브랜치) 메인의 가장 마지막 커밋을 베이스로 삼는다.
- 오래된 순으로 위에서 부터 아래로 목록 나옴 그럼
- squash - 기준이 되는 가장 중요한 커밋을 기준으로 녹여내는 것. 없애는 것 아님! 여기서는 가장 오래된 커밋을 기준으로 녹여내자. 따라서 가장 위에꺼만 빼고 pick ->s 명령어로 바꿔줌
- :wq! 하고 빠져나옴
- 수정용 에디터가 또 나옴
- 커밋 메세지가 여러개 나올 텐데 지우고 하나만 다시 적음
- push -f 를 사용함!
- 충돌해결: 충돌이 생긴 파일을 확인하여 그 파일에 들어가서 해결하고 git add . 커밋은 하지 않고 git rebase --continue 하면 멈춰있던 리베이스가 진행된다.
- 충돌 여러번 날 수 있음. 여러번 날때마다 충돌해결. 계속 해결이 안되면 git rebase --abort로 rebase 진행 전 으로 돌아감
