
rebase를 하는 이유
PR을 할 때 pull을 하면 받아온 파일의 커밋 기록까지 남는다.
커밋 기록이 남으면 pull 받아온 부분도 files changed에 남기 때문에 코드리뷰를 하기 어려워진다.
또한 commit history가 지저분해져서 이전의 커밋을 다시 보기 어려워진다.
그래서 rebase를 하여 깔끔한 PR을 만들어보자.
git pull --rebase 하는 법
- git pull —rebase origin {가져오고 싶은 브랜치명}
- 충돌 해결 (충돌해결 시 기존의 커밋메시지명을 유지한다.)
- git rebase —continue
- ... 충돌 해결과 git rebase --continue 반복
- git push origin {브랜치명} —force
git pull —rebase origin {가져오고 싶은 브랜치명}
원격저장소에서 가져오고 싶은 브랜치의 최신 변경사항을 로컬브랜치로 가져와서 가져온 변경사항 위에 현재 로컬에서 작업중인 커밋들을 다시 적용하는 작업을 수행한다.
충돌 해결 & git rebase --continue
로컬파일과 가져온 브랜치가 충돌이 난다면 충돌을 해결하고 git rebase --continue를 한다.
만약 리베이스 전으로 되돌리고 싶다면 git rebase --abort를 하면된다.
git push origin {자신의 브랜치명} —force
다 되었다면 자신의 브랜치로 push를 한다
이때 반드시 --force를 붙여야 한다. 붙이지 않는다면 내 이전의 커밋이 똑같이 커밋되어서 똑같은 커밋의 수가 늘어난다.
git pull --rebase와 git rebase 차이점
rebase를 하면서 이 두 가지 코드에 대해서 의문을 가졌었다.
가장 큰 차이점은 로컬과 원격저장소이다.
git rebase main
이건 현재 로컬에서 작업 중인 브랜치의 변경 사항을 지정된 main 브랜치의 최신 커밋 위에 재배치하고자 할 때 사용한다.
즉 로컬에 있는 main브랜치의 최신 상태를 가져오고 그 위에 내가 작업한 커밋을 쌓는 것이다.
git pull --rebase origin main
git pull 명령은 기본적으로 git fetch와 git merge의 두 작업을 순차적으로 수행하는데, --rebase 옵션을 사용하면 git merge 대신 git rebase를 사용하여 현재 브랜치의 변경 사항을 원격 브랜치의 최신 변경 사항 위에 재배치(rebase)한다.
원격저장소에 있는 main브랜치의 최신 상태를 가져오고 그 위에 내가 작업한 커밋을 쌓는 것이다.
'개발 > github' 카테고리의 다른 글
| [github] 브랜치 룰 설정하기 (0) | 2024.04.16 |
|---|---|
| [github] github 대소문자 가릴줄 알게 만들기 (0) | 2024.04.03 |
| git pull와 git pull --rebase의 차이점 (0) | 2024.02.23 |
| 깃헙 프로필 꾸미기 (1) | 2023.12.28 |
| git 커밋컨벤션 설정법 (0) | 2023.08.16 |
댓글