ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • TIL.82 Git rebase
    TIL 2020. 12. 30. 13:31
    728x90

    이전까지 프로젝트에서는 단순히 main과 feature 브랜치만 사용했었다.

    추가로 사실 나의 Git PR을 보면 commit 메시지가 생각보다 많은 것을 확인 할 수 있었다.

    이 커밋들은 추후 main 브랜치에 Merge 될 경우 모든 커밋 기록과 함께 Merge commit도 함께 남게된다.

    만약 규모가 큰 프로젝트의 경우 이러한 커밋들로 인해 독립된 브랜치에서 로직 하나를 작성하고 수정하더라도

    다른 작업과 그 내역이 겹쳐 구분하기 어려워지고 main 브랜치를 공유하는 개발자가 많을 수록 커밋의 수는 당연히 많아지는데

    이를 branch history가 복잡해진다고 표현한다. 이러한 문제점을 해결하기 위해서 Rebase를 사용한다고 한다.

     

    먼저 브랜치 병합 방법(전략)으로는 2가지 방법이 있다.

    1. Merge

    2. Rebase

    Merge랑 Rebase랑 같은 기능을 하나 방법이 서로 다르다!

     

    1. Merge - 어떤 브랜치와 다른 브랜치 하나를 사용할 때 사용하는게 머지 (두개의 브랜치를 합치는것)

    https://velog.io/@godori/Git-Rebase

    2. Rebase - 두 브랜치를 합치는 두 번째 방법인 Rebase는 Merge와는 다르게 이름 그대로 브랜치의 공통 조상이 되는 base를 다른 브랜치의 커밋 지점으로 바꾸는 것

    https://velog.io/@godori/Git-Rebase

     


     

    두괄식으로 결론부터 말하자면 Flow는 아래와 같다.

    feature branch (현위치)

    1. git add .

    2. git commit -m "XXX" 

    3. git checkout main 

    4. git pull origin main {로컬 main에서 원격 저장소(remote) main pull} - 원격과 로컬 메인이 같다면 생략

    5. git checkout feature/branch

    6. git rebase -i HAED~2 (현재 브랜치의 커밋은 2개인 상태이다)

    7. 커밋 수정용 에디터_1  -> pick , Squash (S) 설정하고 -> :wq

    8. 커밋 수정용 에디터_2 (1개의 commit 제외하고 모두 삭제) -> :wq

    9. git push origin feature/branch or git push origin feature/branch -f

    (Push 를 한 상태이므로 2번째 push부터 force push로 진행)

     


    Commit history

     

    위 이미지에서 Merge 하게 되면 아래의 이미지와 같이 불필요한 커밋의 갯수가 많아지게 된다.

     


    위의 문제들을 해결하기 위해 Rebase를 사용한다.

    아래 이미지로 보았을때 커밋의 갯수가 줄어듬을 확인 할 수 있고

    이는 프로젝트의 규모가 클수록 더 큰 효과를 나타낼 것이다.


    Merge commit

    아래는 Merge 후 Merge commit (Merge시 자동 생성되는 commit)까지 난것을 볼 수 있다.


    main 브랜치를 feature/signin으로 Merge 받을때 생긴 Merge commit

     

    위 화면을 rebase하면 불필요한 Merga commit이 삭제되어  기존 signin 커밋을 보기 편해진다.

    이렇게 rebase를 사용하면 내 커밋을 최상단(최신커밋)으로 만든다 볼 수 있다.


    Rebase는 내 커밋의 베이스를 변경하여 Commit history를 잘 정렬해준다.


    Rebase의 옵션 중 하나인 Squash를 알아보자

    커밋 흐름을 방해하는 커밋 메시지를 하나의 커밋으로 합칠 수 있다!

    3개의 커밋 메세지를 하나로 묶어 단 1개 의 커밋만 올라 갈 수 있게 도와준다

    (9개 커밋을 각각 3개 커밋으로 바꿀수도 있고, 하나로 묶고나서 언패킹하여 해당 커밋 시점으로 돌아갈수도있다)

     

    위에서 업근한 대로

    첫번째 Push는 잘 되지만

    두번째 Push 부터 아래와 같은 명령이 나오는데

    이유는 rebase를 하며 base가 계속 뒤로 밀려서 base가 계속 바뀌기 때문이다.

    이 경우,  -f 옵션을 사용하여 force push로 진행하면 된다.


    충돌 해결하기

    결국 같은파일을 함께 수정하게 될 겨우 컨플릭트가 발생할 수 있다

    어느 부분에서 충돌이 일어났는지 알려주므로 충돌이 발생하는 부분만 수정해주면 된다.

    여기서 위 이미지의 1, 2, 3 각각 충돌이 모두 일어날 가능성이 높기에 각각 충돌을 해결해줘야하는

    번거로움이 있다.


    아래 git 명령어 참고다

     

    728x90

    'TIL' 카테고리의 다른 글

    TIL.84 Unit Test_실습  (0) 2020.12.31
    TIL.83 Unit Test  (0) 2020.12.30
    TIL.81 Git Flow  (0) 2020.12.29
    TIL.80 AWS_실습2_EC2 & RDS 연동 및 배포  (0) 2020.12.28
    TIL.79 AWS_EC2_실습  (0) 2020.12.27
Designed by Tistory.