본문 바로가기
개발/Git

[Git] 깔끔한 Git 커밋 히스토리 관리를 위한 커밋 스쿼시와 리베이스 작업

by Allonsy 2023. 7. 27.
반응형

commit sqaush (커밋 히스토리 합치기)

커밋 스쿼시를 통해 여러 개의 작은 커밋을 하나로 합치는 방법을 살펴보겠습니다. 작업 과정에서 많은 작은 커밋을 생성하게 되는데, 이를 스쿼시하여 하나의 의미 있는 커밋으로 만들면 커밋 히스토리가 더 깔끔해지고 추적하기도 쉬워집니다.

Before Squash:

      A---B---C---D  feature

After Squash:

      A---BCD  feature

 

Git command:

깃 명령어
$ git rebase -i HEAD~n

여기서 n은 squash를 적용할 커밋의 수입니다. 예를 들어, 마지막 3개의 커밋을 squash하려면 git rebase -i HEAD~3을 실행합니다.

위의 명령어를 실행하면 Git은 편집기를 열어서 선택한 커밋 목록이 나타납니다.

위 명령어 실행 시 열리는 편집기
pick A <commit message>
pick B <commit message>
pick C <commit message>
pick D <commit message>

이후, squash하고자 하는 커밋의 pick squash로 변경합니다.

squash하고자 하는 커밋 수정한 상태
pick A <commit message>
squash B <commit message>
squash C <commit message>
squash D <commit message>

저장하고 편집기를 닫습니다. Git은 커밋 메시지 편집기를 열어 스쿼시된 커밋들에 대한 새로운 커밋 메시지를 작성할 수 있게 합니다. 기본적으로 이전 커밋 메시지들이 모두 합쳐지며, 필요에 따라 편집할 수 있습니다. 저장하고 편집기를 닫습니다.

 

(꿀팁 - 인텔리제이에서 커밋스쿼시하는 방법)

1) Git Window에서 합치고자 하는 커밋을 모두 선택한 후 우클릭 → Sqaush Commimts 클릭

2) 스쿼시 커밋 메시지 작성 후 Ok 클릭하면 스쿼시 진행


rebase (커밋 그래프 하나로 만들기)

리베이스 작업을 통해 기능 브랜치를 메인 브랜치의 최신 상태로 업데이트

리베이스를 통해 기능 브랜치의 커밋들을 재배치하고 충돌을 해결하여 메인 브랜치와 깔끔하게 통합할 수 있습니다

이를 통해 커밋 히스토리를 보다 일관성 있고 직관적으로 관리할 수 있습니다.

 

Before Rebase:

    A---B---C (main)
            \
             D---E---F (feature)

 

After Rebase:

       A---B---C (main)
                      \
                       D'---E'---F' (feature)

 

  1. git checkout main: main 브랜치로 이동합니다.
  2. git pull origin main: main 브랜치의 최신 변경 내용을 가져옵니다.
  3. git checkout <기능 브랜치>: 기능 브랜치로 이동합니다.
  4. git rebase main: 기능 브랜치의 변경 내용을 main 브랜치의 변경 내용 위에 적용합니다. 충돌이 발생할 수 있습니다.
  5. 충돌이 발생한 경우, 충돌을 해결합니다.
  6. git add <파일>: 충돌을 해결한 파일을 스테이징합니다.
  7. git rebase --continue: rebase 작업을 계속합니다.
  8. 필요한 경우 5-7 단계를 반복합니다.
  9. git push --force: 변경된 기능 브랜치를 원격 저장소에 강제로 푸시합니다. (충돌 없을 시 --froce 옵션 없어도됨)

 

이렇게 하면 기능 브랜치의 변경 내용이 main 브랜치의 최신 변경 내용 위에 적용되며, 그래프가 갱신됩니다.

주의할 점은, rebase 작업시 충돌이 발생한 경우 원격 저장소에 푸시할 때는 --force 옵션을 사용해야 하며, 이는 기능 브랜치의 기록을 강제로 덮어쓸 수 있으므로 주의해야 합니다.

필독! Rebase 의 위험성

https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase-%ED%95%98%EA%B8%B0

 

Git - Rebase 하기

Rebase는 기존의 커밋을 그대로 사용하는 것이 아니라 내용은 같지만 다른 커밋을 새로 만든다. 새 커밋을 서버에 Push 하고 동료 중 누군가가 그 커밋을 Pull 해서 작업을 한다고 하자. 그런데 그 커

git-scm.com

Rebase가 장점이 많은 기능이지만 단점이 없는 것은 아니니 조심해야 한다. 그 주의사항은 아래 한 문장으로 표현할 수 있다.

이미 공개 저장소에 Push 한 커밋을 Rebase 하지 마라

이 지침만 지키면 Rebase를 하는 데 문제 될 게 없다. 하지만, 이 주의사항을 지키지 않으면 사람들에게 욕을 먹을 것이다.

Rebase는 기존의 커밋을 그대로 사용하는 것이 아니라 내용은 같지만 다른 커밋을 새로 만든다. 새 커밋을 서버에 Push 하고 동료 중 누군가가 그 커밋을 Pull 해서 작업을 한다고 하자. 그런데 그 커밋을 git rebase 로 바꿔서 Push 해버리면 동료가 다시 Push 했을 때 동료는 다시 Merge 해야 한다. 그리고 동료가 다시 Merge 한 내용을 Pull 하면 내 코드는 정말 엉망이 된다.

반응형

댓글