rebase

willy4202·2022년 5월 10일
0
  1. 깃 플로우의 운영 방식과 main, develop, feature, release, hotfix
  2. rebase와 merge의 차이점
  3. rebase에서 squash할 수 있다.

Git Flow

기존에 진행하던 merge 방식은 feature로 새로운 브랜치를 만들어 각각의 기능을 만들어 병합하는 방식이다. 이 방식은 conflict도 발생하기 쉽고, 테스트 과정도 없다. 만약 메인 브랜치 하나에서 서비스를 한다고 가정했을 경우, 리스크가 매우 큰 방식이다.

메인 브랜치 이전에, 미리 테스트해볼 수 있는 브랜치를 만들어 진행할 수 있다. 이를 develop 브랜치라고 부른다.

디벨롭 브랜치에서 새로운 브랜치를 만들어 각각 feature 브랜치를 만들어 develop 브랜치에 던진다. 이제 디벨롭 브랜치에 머지가 된다면, 개인이 작업하고 있는 브랜치에 pull을 받아서 진행한다.

그렇다면 이 디벨롭 브랜치를 바로 메인에 병합하는가? 그건 아니다. 사전에 해당 코드를 테스트하는 release라는 브랜치를 만든다. 이를 개밥먹기라고 한다.

배포 이전에 테스트를 위해 만드는 브랜치다. 여기서 테스트가 끝나고 메인브랜치에 병합시키는 방식이다.

QA를 거치고, 버그 픽스를 거쳐도 버그가 발생할 수 있다. 실제로 서비스가 되고 있는 제품에 문제가 생긴다면 바로 hotfix라는 브랜치를 파서 대처한다. 일종의 테스크 관리 방식이라 보면 된다.

이는 마이너한 버전이라 1.0.~~이라는 말로 표기한다.

이런 플로우를 거친다면, 리스크를 줄일 수 있다.
이런 관리를 위해 git flow init이라는 명령어가 따로 있을 정도다.
지금까지 진행해온 프로젝트 방식과는 많이 다른 방식이다.
현재 프로젝트는 효율적인 진행을 위해, feature로만 적용한 것이다.

서비스 브랜치, 개발자 브랜치를 나눠서 작업하는 것이 기본적인 플로우라고 생각할 수 있다.


rebase

merge와 rebase는 한 브랜치의 변화를 다른 브랜치로 병합하기 위한 명령지만, 작동 방식은 전혀 다르다.

그렇다면 merge가 아닌 rebase를 사용하는 이유는 무엇일까?

기존의 머지 방식은 다른 브랜치에서 병합을 진행하면, 새로운 브랜치에서 기존의 커밋이 쌓이게 된다. 즉, 불필요한 커밋이 계속해서 쌓이는 셈이다.

다시 feature에서 maind으로 병합하게 된다면, 더 복잡한 커밋이 메인 브랜치에서 쌓이게 되는 것이다. 커밋 찍혔던 목록을 살펴보면, 머지커밋이 굉장히 많이 찍혀있는 것을 볼 수 있다.

이렇게 복잡하게 쌓이게 된다면, 어떤 커밋이 무슨 역할을 하는지 파악하기 힘들고, 버그가 어느 커밋, 어느 브랜치에서 발생했는지 역추적하기가 힘들어진다.

프로젝트의 규모가 커질수록 브랜치의 히스토리가 지저분해지는 문제가 생긴다.
또한, 복잡한 프로젝트 히스토리때문에 다른 내역과 겹쳐 구분이 어려워진다.

그럴때, rebase를 사용하게 된다면 비교적 깔끔하게 프로젝트를 확인할 수 있다.

rebase는 작업한 목록들을 뭉쳐두고, 머지 커밋을 남기지 않기 때문이다.

rebase

베이스는 기준점이라는 뜻을 가지고 있다. rebase는 기준점을 다시 만든다는 개념으로 접근하면 이해가 쉽다. 처음 메인 브랜치에서 가지가 뻗어나가는 방식으로 작업을 한다.

rebase는 커밋의 베이스를 변경해서 히스토리를 정리해준다. 베이스를 바꾸고, 같은 내용의 커밋을 새롭게 진행하는 방식이기 때문이다.

그러나 리베이스는 컨플릭트가 조금 더 많이 발생할 수 있는 문제가 있다. conflict는 커밋과 커밋사이 변동 사항의 충돌로 인해 발생하는 것인데, merge는 마지막끼리만 비교해서 conflict를 해결할 수 있는데, rebase는 각각의 커밋마다 충돌이 발생 할 수도 있다.

이를 방지하기 위해서는 커밋이 쌓이기 전에 rebase를 진행하는 것이 좋다.
즉, 커밋을 너무 쌓아두지는 말자.


squash

스쿼시는 커밋들을 하나로 묶어주는 기능이다. rebase를 진행하는 과정에서 이를 적용해볼 수 있다.

개인 작업 브랜치에서 main 브랜치로 병합해야하는 상황이 있을 것이다. git rebase -i main을 진행하면, -i는 interaction의 약어로 vim에디터로 진행할 수 있게 도와준다.

picks라는 명령어를 통해 커밋을 하나로 녹일 수 있다.
반드시 제일 위에 있는 커밋을 픽해줘야한다. 가장 상단에 있는 커밋이 최신화된 커밋이기 때문이다.
그 아래에 있는 커밋들은 s 로 바꿔주면 된다.

에디터를 닫는 순간 에디터창이 하나 더 뜰 것이다.
여기서는 실제로 rebase된 커밋의 내용을 작성하는 에디터로, 현재까지 적은 커밋이 모두 등장한다.

불필요한 내용을 모두 제거하고 현재 수정 내역에 대한 커밋 메시지를 작성하면 된다.
이제 모든 커밋을 rebase로 정리해줄 수 있다.

그런데 막상 푸쉬를 하려고 하면 거절하는 모습을 볼 수 있다.

로컬과 원격 저장소상의 히스토리가 다르기 때문에 출력하는 문구다.
그럴 땐 force로 밀어주면 된다.


rebase 실습

이제부턴 merge가 아니라 rebase로 진행한다. 그렇게 되면 한 pr당 하나의 커밋만이 남게 된다.

개인 작업 브랜치로 들어가 git rebase -i main

컨플릭트 대처법

만약 rebase를 진행하던 중 충돌이 생긴다면, 커밋의 id를 그려주며, git rebase --continue라는 명령어를 입력하라는 문구를 보여준다.

충돌난 코드를 수정한 다음, 계속해서 rebase를 진행하면 된다.

만약 리베이스를 하지 않길 원한다면 git rebase --abort를 입력해주면 된다.

profile
성장,,하고싶다

0개의 댓글