git rebase 명령어를 무작정 사용하기 이전에 git merge
를 두고 왜 git rebase
를 써야하는지부터 언급하려한다.
git merge
를 사용해서 많은 개발자들이 큰 규모의 프로젝트를 작업해야하는 상황이라 가정해보자.
각 각의 feature 브랜치가 머지될 때마다 "merge commit"이 남는다. 불필요한 커밋이 남는 셈이다.
commit history가 아래의 이미지처럼 복잡해진다. git merge
는 시간 순서로 정렬되기 때문에 다른 브랜치에서의 커밋 이력들이 겹쳐 추적이 어렵다.
반면, git rebase
를 이용한다면 같은 작업을 진행한 commit 끼리 모아주기 때문에 커밋 히스토리를 깔끔하게 관리할 수 있다.
각 branch에서 작업하다가 여러개의 commit 이 생기면 rebase로 병합해준다.
기존에 작업하던 브랜치를 remote에 push 하기 전 main 으로 가서 pull 진행을 먼저 해야한다. (아래와 같은 순서로 진행!)
$git add .
$git commit -m "commit 메세지"
$git checkout main
$git pull origin main // main 브랜치를 최신화
$git checkout feature/login
$git rebase -i main //
1.여러개의 commit 들 앞에 pick
이라고 적혀있다. 가장 오래된 commit을 pick으로 둔다.
📌
p, pick
: 해당 커밋을 수정하지 않고 그냥 사용하겠다 라는 명령어이다.
텍스트 에디터로 들어오면 커밋에 pick 명령어가 디폴트 값이다.
s, squash
: 여러개의 커밋 메세지를 하나로 합치는 명령어로로 커밋 히스토리를 깔끔하게 관리할 수 있다. git log에서 합쳐진 커밋 메세지를 확인할 수 있다.
2.나머지 commit 메세지들은 pick
대신 squash
혹은 s
라고 입력후 esc -> :wq로 저장하고 창에서 빠져나온다.👇🏻
3. 수정용 에디터가 하나 더 나타난다. 아래와 같이 현재까지 적은 커밋 메세지들 목록이 보일 것이다.👇🏻🏻
4. 하나의 커밋 메세지만 남기고 나머지는 지워준다. 남길 커밋 메세지에는 해당 branch를 대표하는 커밋 메세지이니 상세하고 신중하게 적어준다. 작성이 끝나면 esc -> :wq로 빠져나온다.
git push origin [branch 명]
충돌된 부분의 코드를 수정 후,
$ git add . // add 후 commit 은 하지않는다.변경된 내용이 없기 때문에
$ git rebase --continue // 멈춰있던 rebase 가 진행된다.
충돌이 여러번 일어나면 그 때마다 충돌된 부분을 수정하여 해결하고
git add .
-> git rebase --continue
를 반복한다.
(commit을 한 만큼 오류가 발생될 것이니..겁먹지말자..)
위 과정이 끝나면,
$ git push origin [branch 명]
만약 아래와 같은 오류 메세지가 나온다면,(git은 history 가 다른 branch의 푸쉬를 허용하지 않기 때문에 에러가 발생한다)
아래의 명령어로 force push를 진행한다.
$git push origin [branch 명] -f
그래도 해결이 안되면, 아래의 명령어로 rebase 를 진행하기 전 상황으로 돌아갈 수 있다.
$git rebase --abort
혹은 git reflog로 [돌아갈 지점]을 찾은 후 git-reset --hard [돌아갈지점] 명령어로 복구할 수 있다.
📌 <git rebase 사용 시 주의사항>
- 이미 공개 저장소(remote)에 push한 커밋을 Rebase 하지 말 것!
- rebase는 혼자 작업하는 브랜치에 한해서만 해야한다. 여러 사람이 한 브랜치에서 작업하는 경우에 rebase를 사용하면 꼬일 수 있다.
출처 ) wecode 에서 제공하는 학습 자료 참고