|
|
| 1번째 줄: |
1번째 줄: |
| 깃 리베이스(Git rebase)는 한 브랜치의 커밋들을 다른 기준(베이스) 커밋 위에 다시 적용하는 작업이다. 즉, 브랜치의 기반을 새 커밋 위로 옮기면서 커밋 히스토리를 재작성하는 수단이다.
| | #넘겨주기 [[Git Rebase]] |
| ==개념 및 원리==
| | 오타 |
| 리베이스는 “현재 브랜치에 있는, 아직 기준(upstream)에 포함되지 않은 커밋들”을 임시로 떼어낸 뒤, 목표 기준 커밋(또는 브랜치)의 최신 상태 위에 하나씩 다시 적용함으로써 새 브랜치가 시작된 것처럼 보이게 만든다. 이 과정에서 사실상 커밋은 새로 생성되며(기존 커밋은 대체됨), 커밋 ID가 변경된다.
| |
| | |
| 예를 들어 다음과 같은 히스토리가 있을 때, 현재 브랜치가 `topic`이고 기준이 `master`라면:<syntaxhighlight lang="text">
| |
| A --- B --- C (topic)
| |
| /
| |
| D --- E --- F --- G (master)
| |
| </syntaxhighlight><syntaxhighlight lang="bash">
| |
| git rebase master
| |
| </syntaxhighlight>명령을 실행하면, 결과는 다음과 같은 모습이 된다:<syntaxhighlight lang="text">
| |
| D --- E --- F --- G --- A' --- B' --- C' (topic)
| |
| </syntaxhighlight>즉, `topic`의 커밋들이 `master`의 최신 커밋(G) 뒤에 붙는 형태가 된다.
| |
| | |
| 리베이스가 실패할 경우(충돌이 발생하면), Git은 멈추고 충돌 상태를 남긴다. 이때 사용자는 충돌을 해결한 뒤<syntaxhighlight lang="bash">
| |
| git rebase --continue
| |
| </syntaxhighlight>명령으로 계속할 수 있고,<syntaxhighlight lang="bash">
| |
| git rebase --skip
| |
| </syntaxhighlight>를 사용해 해당 커밋을 뛰어넘을 수도 있다. 만약 리베이스 자체를 취소하고 싶다면<syntaxhighlight lang="bash">
| |
| git rebase --abort
| |
| </syntaxhighlight>명령으로 원래 상태로 복귀할 수 있다.
| |
| ==리베이스 모드 및 옵션==
| |
| 리베이스에는 여러 모드와 유용한 옵션들이 존재한다.
| |
| ===기본 모드===
| |
| <syntaxhighlight lang="bash">
| |
| git rebase <upstream>
| |
| </syntaxhighlight>형태로 쓰며, 현재 브랜치를 `<upstream>` 브랜치의 최신 커밋 위에 다시 재배치한다.
| |
| ===대화형 리베이스(interactive rebase)===
| |
| <syntaxhighlight lang="bash">
| |
| git rebase -i <base-commit>
| |
| </syntaxhighlight>옵션 `-i`를 붙이면 리베이스를 대화형으로 수행할 수 있다. 이 모드에서는 리베이스 과정에서 다음과 같은 작업이 가능하다:
| |
| *커밋 순서 변경
| |
| *커밋 삭제(drop)
| |
| *커밋 병합(squash, fixup)
| |
| *커밋 메시지 수정(reword)
| |
| *특정 커밋에서 중단 후 수정(edit)
| |
| 이 기능은 개발 중 발생한 불필요한 커밋을 정리하거나 더 깔끔한 히스토리를 만드는 데 유용하다.
| |
| ===주요 옵션===
| |
| *--onto <newbase>: 리베이스할 때 기준을 새 베이스로 지정
| |
| *--keep-base
| |
| *--reapply-cherry-picks
| |
| *--no-verify 등
| |
| (자세한 옵션은 `git rebase --help` 또는 Git 문서 참조)
| |
| ==장점과 주의점==
| |
| ===장점===
| |
| *히스토리의 직선성 유지 가능 — 불필요한 병합 커밋 없이 깔끔한 커밋 흐름을 유지할 수 있다.
| |
| *충돌 해결을 커밋 단위로 관리 가능 — 하나의 충돌이 전체 병합을 막는 대신, 각 커밋마다 충돌을 처리할 수 있다.
| |
| *커밋 정리 및 정돈 가능 — 대화형 리베이스를 통해 중복 커밋 제거, 메시지 수정 등이 가능하다.
| |
| ===주의점 / 단점===
| |
| *리베이스는 히스토리를 재작성하므로, 이미 원격 저장소나 다른 사람과 공유된 커밋을 리베이스하면 충돌과 작업 손실 위험이 크다.
| |
| *리베이스 중 여러 충돌이 발생할 수 있으며, 특히 긴 기간 동안 작업한 브랜치일수록 복잡해질 수 있다.
| |
| *커밋 메타데이터(작성자, 커밋 시간 등)가 변경될 수 있다.
| |
| *리베이스가 꼬였을 때 복구가 어렵거나 까다로울 수 있다 — `git reflog` 등을 활용해야 한다.
| |
| ==사용 시나리오 및 팁==
| |
| *개인 작업 브랜치에서는 리베이스를 자유롭게 사용해도 좋지만, 공동으로 작업하는 브랜치에서는 주의해야 한다.
| |
| *리베이스 후 원격에 푸시할 때는 --force-with-lease 옵션을 사용하는 것이 안전하다.
| |
| *리베이스 전에 백업 브랜치를 남겨 두는 습관이 좋다.
| |
| *리베이스가 꼬여버렸다면 `git reflog`로 이전 커밋을 찾아 복구할 수 있다.
| |
| ==같이 보기==
| |
| *[[Git merge]]
| |
| *[[Git 워크플로우]]
| |
| *[[Git reflog]]
| |
| *[[Git 브랜치]]
| |
| *[[Git commit]]
| |
| ==참고 문헌==
| |
| *Scott Chacon & Ben Straub, ''Pro Git'' (Apress)
| |
| *Git 공식 문서 — git‑rebase 매뉴얼
| |
| *Atlassian, “Git rebase” 튜토리얼
| |
| *Julia Evans, “git rebase: what can go wrong?” 블로그
| |
| ==각주==
| |
| [[분류:형상관리]]
| |
| [[분류:Git]]
| |
