Nice To Have
- 커밋 재작성
- 커밋 수정 및 스쿼싱(결합)
- 커밋 삭제
rebase -i 명령어를 통해서 이미 존재하는 커밋 이력을 편집, 조작할 수 있다.
reword, edit 등 수정사항이 여러개라면 각 커밋마다 작업을 하나씩 순차적으로 해주어야 한다.
변경 작업이 완료되면 커밋 해시가 바뀌게 된다. 즉, 작업 대상의 커밋들이 모두 재생성 되었다는 얘기이다.
추가로 특정 브랜치를 지정하지 않고 현재 HEAD가 위치한 브랜치를 기점으로 리베이스를 하게된다.
git rebase -i [commit-hash]
pick : 커밋 유지
reword : 커밋 유지. 단, 커밋 메시지만 재작성
edit : 작업과 커밋 메시지 모두 재작성
fixup : 이전 커밋과 병합. 단, 커밋 메시지는 병합하지 않는다. (squash와 기능적으로 동일)
![](https://blog.kakaocdn.net/dn/boqvbi/btrQpUBveUT/Rzl5rCeqE3OhOygKJI4y20/img.png)
![](https://blog.kakaocdn.net/dn/0084I/btrQpIajr1p/abWLExpLjIh0bIBrRG0QBk/img.png)
drop : 커밋 삭제
squash는 fetch/pull의 미묘한 차이처럼 fixup 이후 reword를 실행한 것과 같다고 보면 된다.
보통 작업중인 피처 브랜치를 공유하기 전에 interactive rebase를 통해서 커밋 이력들을 정리한다.
바로 직전 커밋 하나만을 수정하는 경우라면 amend를 사용하는 것이 간편하다.
'프로그래밍 > Git & Github' 카테고리의 다른 글
[Git & Github] 18. Git의 이면 - 해싱(Hashing)과 객체 (0) | 2022.11.05 |
---|---|
[Git & Github] 17. Git tag: 히스토리상의 중요한 순간에 표시하기 (0) | 2022.11.04 |
[Git & Github] 15. 리베이스(Rebase)는 가장 까다로운 Git 명령어일까? (0) | 2022.10.27 |
[Git & Github] 14. Git 협업 워크플로우 (0) | 2022.10.26 |
[Git & Github] 13. Github의 이모저모: 잡다한 지식 (0) | 2022.10.25 |