add 했고 push했고 pull 받아서 conflict까지 해결하고 merge가 된순간 이제 끝났다고 생각했다... 그러나 아직 한발 남았다....

Git Rebase가 뭐죠?

rebase 는 단어 그대로 베이스(base)를 재(re)배치하는 것을 말한다.
우리가 기존에 사용하던 merge를 사용하면 히스토리를 확인할때 뿌리가 여러개로 나눠져 있어서 확인하기가 어렵다. 이러한 불편함을 해결하기 위해 우리는 rebase를 통해 여기저기 뿔뿔이 흩어져있던 혹은 홧김에 아무말이나 써버렸던 커밋 라인을 정리하여 히스토리를 깔끔하게 볼 수 있게 해준다.

Rebase 과정

1. 우선 여러 작업들을 진행하면서 commit을 차곡차곡 쌓아간다.

의미없는 커밋은 지양해야겠지만 우리는 이제 rebase라는 것을 배울 예정이므로 배운걸 이용해서 잘 정리할 자신만 있다면 어쨌든 커밋은 많이하면 할수록 좋다고 생각한다. 언제 무슨일이 생길지 모르므로...
그럼 이제 작업중인 branch에서 git rebase -i master를 이용해서 rebase를 시작하자.

숨기고 싶은 나의 작고 소중한 커밋들...이지만 나중에 추억하기 위해 이곳에 남겨두겠습니다..

2. 하나의 커밋만 pick으로 남겨두고 나머지 커밋들 앞은 s 로 바꿔서 입력해준다. 가장 위에가 가장 초기 커밋이다.

여기서 s는 squash를 뜻한다. 즉 나머지 과거의 커밋들은 짓눌러서 으깨버리면 된다. (네이버사전 기준)

:wq로 저장하고 나간다.

3. 그럼 이제 그동안 남겼던 커밋메세지들을 하나의 커밋메세지로 정리해준다.

mac 기준 i 눌러서 입력모드로 바꾸기 전에 지우고 싶은 줄로 가서 dd를 누르면 한줄이 삭제된다. 이런 사소한거에 행복을 느끼는게 정상인가...

:wq로 저장하고 나간다.

4. git log로 깔끔해진 나의 커밋들을 확인한다.

5. 이제 다 줄였으니 push를 해봅시다.

but 여기서 주의할 점은...!
아무도 squash 한 commit들을 pull 하지 않았다는 가정 하에 위 작업들이 수행되어야 한다는 것이다. 누군가 이미 내가 올렸던 commit들을 pull 했는데 그걸 rebase 를 통해 수정하고 commit 한다면 큰일이 날 수 있다.

그렇기 때문에 친절하게도 이러한 경우를 방지하고자 이미 squash 하지 않은 commit들을 push했을 경우 squash한 commit을 push 하면 거부당하는 걸 확인할 수 있다.

이러한 경우들 덕분에 정상(?)적인 경우 PR/branch 당 커밋이 하나여야 한다는 점을 잊지말자.

만약 아무도 내 커밋을 pull 하지 않았다고 확신한다면 그냥 강제로 넣어버리면 된다.

git push origin <branch-name> --force

확신없는데 사용하면...그랬다가는 썸네일의 모습이 내 미래가 될지도 모른다..

etc

rebase 도중 충돌이 일어날 경우 마치 코드가 날아간 것처럼 보일수 있다. 그러나 코드가 사라진 것이 아니라 코드를 합치던 도중 충돌이 일어나서 중단된 것이므로 충돌을 해결해주고 다시 진행하면 모든 코드를 다시 찾을 수 있을 것이다.

만약 잘못 rebase 했다면?

git rebase --abort (리베이스 도중) 혹은 git reflog 로 돌아갈 지점을 찾은 후 git reset --hard 돌아갈지점 (리베이스 완료 후) 명령어로 복구할 수 있으니 걱정하지 않아도 된다...?라고 하는데 그래도 걱정되는게 정상이니까 대신 조금덜 걱정하면 된다.

충돌 발생시 에디터에서 충돌 해결 후 git add . -> git rebase --continue를 반복하되, 커밋을 해줄 필요는 없다.

너무나도 예민한 우리 Git.... 앞으로도 잘 지내보자