안녕하세요! 1-tier 팀의 one입니다.
이제 제법 날씨가 쌀쌀해졌네요
오늘은 Git의 Rebase에 대해서 알아보도록 하겠습니다.
🤔 브랜치 병합
Git에서 한 브랜치에서 다른 브랜치로 합치는 방법에는 두 가지가 있습니다.
하나는 Merge고 하나는 Rebase 입니다.
여기서 Merge가 뭔지 간단히 한번 볼까요?
Merge
브랜치가 experiment와 master로 나누어졌다고 가정해봅시다.
두 브랜치를 합치는 가장 쉬운 방법이 Merge 명령어를 사용하는 것입니다.
커밋 두개(C3, C4)와 공통조상(C2)를 사용하는 3-way Merge로 새로운 커밋(C5)을 만들어냅니다.
그렇다면 Rebase는 어떤 방식으로 병합이 이루어질까요?
Rebase
rebase의 방식은 다음과 같습니다.
C3에서 변경된 사항을 Patch로 만들고, 이를 다시 C4에 적용을 합니다.
🔎Git Patch
Commit을 하나의 Patch 파일로 만들 수 있다.
패치를 이메일로 보내거나 여러개의 커밋을 하나의 패치로 만들 수 있다.
rebase에 대해 자세히 한번 살펴봅시다.
먼저 Checkout한 브랜치(experiment)가 가르키는 커밋까지 diff를 만들어 어딘가에 임시로 저장합니다.
Rebase 할 브랜치(experiment)가 합칠 브랜치(master)가 가르키는 커밋을 가르키게 한 후, 저장해놓았던 변경사항을 차례대로 저장합니다.
Rebase는 아래와 같은 명령어로 실행이 가능합니다.
git checkout experiment
git rebase master
Rebase 과정 후에 master 브랜치를 Fast-forward merge 합니다.
🔎Fast-forward
현재 브랜치의 HEAD가 대상 브랜치의 HEAD까지로 옮기는 merge
git checkout master
git merge experiment
rebase 병합을 하는 경우엔, git merge를 했을 때 보다 변경 이력을 알기가 쉽습니다.
🚫 Rebase 주의사항
✔ 이미 공개 저장소에 Push한 커밋을 Rebase 하지마라
Rebase는 기존의 커밋을 그대로 사용하는 것이 아니라, 내용은 같지만 다른 커밋을 새로 만듭니다.
커밋을 git rebase로 바꿔서 push 할 경우, 동료가 다시 push 했을 때 동료는 다시 merge를 해야합니다.
🛠 Rebase 한 것을 다시 Rebase 하기
어떤 팀원이 강제로 내가 한 일을 덮어썼다고 할 때, 덮어쓴 내용이 무엇인지 알아내야 합니다.
아래와 같은 명령을 실행하면, 덮여쓰여지지 않은 커밋을 결정하여 새로운 브랜치에 적용합니다.
git rebase teamone/master
Push하기 전 History 정리를 위해 사용하는 것은 가능 하지만,
별도의 알람없이 history를 임의로 변경시키기 때문에 주의가 필요합니다
git pull --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
그럼 다음 시간에 만나요!
'INFRA > DevOps' 카테고리의 다른 글
kind (1) | 2023.10.13 |
---|---|
Flask + gunicorn + nginx 연동 (1) | 2023.10.11 |
[DevOps] Jenkins-Git webhook 설정 (0) | 2023.10.04 |
[K8S] Log (1) | 2023.10.03 |
[Git] Github Action (0) | 2023.09.18 |
댓글