1. Rebase란
1) rebase vs merge
M1에서 branch를 생성하고, M2, B1, M3, B2 순서로 commit을 한 후
Merge를 하게 되면 commit history가 보라색 선 처럼 M1->M2->B1->M3->B2 순서로 되기 때문에 commit history가 어지럽혀진다.
하지만 branch에서 base의 위치를 바꾸어주는(base란 branch가 뻗어나온 commit) rebase를 branch에서 해주게 되면 base의 위치가 master branch의 최근 commit으로 바뀌게 된다.
rebase 후 master branch에서 branch를 Merge해주게 되면 commit history가 깔끔하게 정리 되는것을 볼 수 있다(초록 선)
따라서 rebase를 하냐 merge를 하느냐의 논리가 아니라
1. merge를 하느냐
2. rebase 후 merge를 하느냐
이렇게 두가지를 비교해야 한다
2. Rebase를 하는 이유
1) Git History
GitHub commit history는 프로젝트의 성장과 진행 과정을 나타내는 기록이다. 따라서 프로젝트의 규모가 방대해지고, 참여하는 팀원의 수가 증가 할 수록 commit history를 잘 관리해야 하는 필요성이 증가한다.
따라서 commit의 순서를 명확하게 해주기 위해 rebase를 사용해야 한다.
2) Edit Commit
작업 할때는 몰랐는데 commit message에 오타가 있을 수 있고, 테스트용으로 작성한 commit이 추가 되었을 수 있다. 이때 commit을 수정하기 위해 rebase를 사용한다.
3. Rebase 하는 방법
1) base의 위치를 변경해주기 위한 rebase
#in some branch
$ git rebase master2) commit message를 바꾸기 위한 rebase
git rebase -i ${수정할 커밋의 직전 커밋}
# 커밋 해시를 이용한 방법
git rebase -i 9d9cde8
# HEAD를 이용한 방법
git rebase -i HEAD~3이렇게 명령어를 입력하게 되면 vim에디터가 나오게 된다.
위에서 수정하려고 하는 commit을 pick 대신 reword로 변경 후, 저장 종료 하면
commit message를 수정 할 수 있는 vim 에디터를 만날 수 있다.
위의 창에서 commit message를 변경 후, 저장 종료 해주면 commit message가 수정되는 것을 볼 수 있다.
3) commit message를 압축하기 위한 rebase
git rebase -i ${압축 하고 싶은 commit의 위치}
# HEAD를 이용한 방법
git rebase -i HEAD~3이렇게 입력하게 되면 위의 commit message를 변경 했던 것 처럼 각 commit마다 옵션을 줄 수 있다.
이때 합치고 싶은 commit message에 squash 옵션을 주고(squash해준 commit 이전의 commit에 합쳐짐)
저장 종료 해주면 되는데, 이때 합쳐지는 commit message도 변경 가능하다!!
4. Rebase -i option
- pick, p => 수정 없이 사용하겠다
- reword, r => commit message를 변경하겠다
- edit, => commit message뿐 아니라 내용도 수정하겠다
- squash, s => 이전의 commit과 합치지며 commit message가 합쳐짐
- fixup, f => 이전의 commit과 합치지만 이전의 commit message만 남겨짐
5. Rebase 주의점
rebase의 장점이 매우 많지만 rebase는 commit 수정이 아니라 삭제 후 생성의 관점으로 바라봐야 한다.
삭제 후 생성 되기에 Hash값이 변경된다. hash값이 변경 된다면 어떤 문제가 생길지 생각해보면
1. 나 혼자 작업할때는 크게 문제가 되지 않는다.
2. 하지만 팀 동료들이 master에 PUSH 된 기본 틀이 되는 코드를 받아 각자의 작업을 하고 있는데
3. 이때 push된 commit을 rebase하게 된다면 해당 commit들의 hash값이 변경 되고
4. 동료들은 본인들의 commit의 hash값을 하나하나 수동으로 변경해주어야 하는 일이 발생 할 것이다.
5. 동료들이 혹여나 commit의 hash값을 수정해주지 않느다면, 이미 사라진 commit을 base로 두고 있는 경우가 생길 것이고
6. 그렇게 된다면 commit history가 아주 엉망이 될 것이다.
6. conclusion
🚨rebase는 꼭꼭꼭 push된 commit이 아닌 내가 작업중인 commit에 대해서만 해주는것이 정신건강에 좋다🚨
rebase에 대해 처음 듣고 설명을 듣고 rebase에 대해 정확하게 이해하기까지 주말포함 5일은 소요가 되었다.
다른것도 같지만 git에 대해서는 대충 알고가면 절대 안된다고 생각했다. 왜냐하면 나의 실수가 나의 팀원에게 피해를 줄 수 있고, 대충 알고 사용한다면 절대 활용을 할 수 없을것 같았기 때문이다.솔직히 몇번이고 이해가 되지 않아 포기하고 싶기도 했지만, 조금씩 이해가 되어가는 과정이 너무나도 즐거웠고 그 결과 rebase에 대해 나름의 기준이 생겼고, 어떻게 활용할지에 대한 생각을 하게 되었다.
느리더라도 정확하게 알고가자🔥
21.08.18 위코드 3주차 수요일
