Git의 깔끔한 commit 관리 Git Rebase에 대해 알아보자 😀
Rebase란?
rebase는 말 그대로 (re-base)로 베이스를 재배치한다는 뜻이다
merge를 사용하면 히스토리를 볼 때 뿌리가 여러개로 나눠져 있어서 히스토리를 찾아갈 때 보기가 어렵다
rebase는 베이스를 다시 정의함으로써 새롭게 커밋 라인을 정리하여 히스토리를 깔끔하게 볼 수 있게 해준다
이런 복잡한 브랜치 구조는 개발자들이 history를 파악할 때 문제를 추적하기에 복잡하다
그래서 Git rebase를 사용한다.
Git Merge 와 Git base 비교
마스터에 변경사항이 내가 작업하는 것에 관련이 있고 필요로 할 때 그것을 우리의
feature branch에 합치기 위해서는 우리에게는 두 가지 옵션이 있다.
한 가지가merge이고 다른 방법은rebase이다
Git Merge
-
장점 : 존재하는 branch와 commit을 바꾸지 않는
non-destructiveoperation이다.
( 이것은git rebase가 갖는 잠재적 위험을 피할 수 있게한다 ) -
단점 : 반면에 상위 branch 및 master로 update을 필요로 할 때마다 매번 commit을 해야 하기에 엄청난 양의 commit 기록이 쌓이게 된다.
( If master is very active, this can pollute your feature branch’s history quite a bit. )
-
방법 :
1) 로컬 마스터로 가서git pull origin master로 로컬 마스터 업데이트
2)git checkout feature/브랜치명브랜치 이동
3)git merge mastermerge master branch into feature branch
Git-Rebase
-
아래 그림처럼 전체의
feature branch를master branch로 옮기는 형태이다.
( merge commitd이 아니라 master를 rebase 시작점을 바꾼다는 의미이다 ) -
장점 :
1) git merge를 하기 위해 불필요한 commit들을 제거해준다.
2) 아래와 같이 완벽하게 직선의 project history를 남게 하여 시작할 때 feature의 끝만 추적하면 된다. -
단점 :
1) 제대로 사용되지 않을 시 re-write project history는 협업 workflow에 잠재적으로 큰 재앙이 될 수 있다.
2) 상위의 변화 언제 feature에 합쳐졌는 지에 대한 맥락(contenxt)를 잃게 된다.
How to use?
-
작업 ,
git add .git commit -
git checkout master -
`git pull origin master
-
git checkout feature여기까지는 merge와 똑같다
-
git rebase -i master
-
commit목록 중 제일 상단 commit을 p(pick) 나머지를 s(squash)로 지정
-
conflict가 뜨면 수정 후
git add .,git rebase --continue반복 -
수정 후 successfully rebased and updated 가 뜨면
git push orign feature
-
rejected 시
git push origin feature --force로 force push한다.
요약
- 만약 불필요한 커밋내역 대신 깨끗하고 직선형의 히스토리 관리를 선호한다면
git rebase- 반면에 전체의 project history 내역을 보존하길 원하고 public commits을 re-write하는 리스크를 피하가고 싶을때
git merge를 고수하면 된다!!.
