[TIL] Git Flow & Git rebase

나른한 개발자·2022년 2월 20일
0

studylog

목록 보기
36/45

오늘 살펴볼 것은 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 진행 전 으로 돌아감
profile
Start fast to fail fast

0개의 댓글