-
git rebase프론트엔드 개발자가 될거야./git 2022. 8. 14. 21:38
- Merge 와의 공통점 → 브랜치를 합친다!
- Merge 와의 차이점
→ Merge보다 깨끗한 commit history를 만든다! → Merge와는 다르게 선형적으로 그려진다!
어떻게 commit history를 깨끗하게 만들까?
Rebase는 현재 브랜치의 베이스를 재설정해서 합치겠다는 것이다.
→ base가 바뀔 commit들을 복사해서 연이어 붙이는 것이다!
요약.
- Merge보다 깨끗한 commit history를 만든다! → Merge와는 다르게 선형적으로 그려진다!
- 현재 브랜치의 base를 바꾸겠다는 것이다!
- : 생성된 커밋들은 새롭게 복사되어 base가 변경된다.
- Rebase 주의점!
복잡한 conflict! 커밋을 너무 쌓아두면 안된다!!
더이상 merge 하지마라. commit도 하지말라!
<새로운 작업을 모두 마치고 push 하기 전에는>
- main branch로 이동하여 remote main을 pull 받는다.
- 내가 pull 할 feature branch로 이동한다.
- git rebase -i main 을 진행한다.
<Rebase 하는 동안 squash 진행할 때에는>
- (i를 눌러서) 가장 오래된 commit을 pick 한다.
- 다른 커밋 메세지는 가장 오래된 commit을 기준으로 squash 한다.
- 다른 커밋의 작업 내역이 없어지는 것이 아닙니다.
- Esc -> :wq! 로 창에서 빠져나온다
<놀라지 마세요! 수정용 에디터가 하나 더 나타납니다.>
- 최종적으로 이 rebase된 커밋의 내용을 작성하는 부분.
- 현재까지 적은 커밋 메세지가 전부 나타난다.
- 불필요한 내용을 제거하고 현재 수정 내역에 대한 커밋 메세지를 정성껏 작성한다.
- Esc -> :wq! 저장하고 에디터에서 빠져나온다.
<Successfully rebased !>
- 성공했다면 git log로 깔끔해진 커밋 메세지를 한 번 감상한다.
- push를 합니다.
<Rebase 후 push 하기>
- Rebase는 commit history를 정리하는 역할을 한다.
- 같은 브랜치에서 Rebase를 할 때마다 history가 달라질 수 있다.
- 수정 사항이 추가로 생긴 후 다시 rebase하면 history가 무조건 달 라진다.
- git은 history가 다른 branch의 push를 허용하지 않는다.
- git push origin feature/login -f -f 옵션을 사용하여 force push를 진행한다. (pr을 하는 곳도 있음. 상황에 따라 선택하기.)
<Rebase 중 충돌 해결하기 방법1>
git reflog → 돌아갈 지점 찾은 후 → git reset —haed 복붙
→ git add . → git rebase —continue → 커밋은 노노노!!!!
<Rebase 중 충돌 해결하기 방법2>
- 충돌이 일어난 경우 Rebase가 진행되지도, 끝나지도 않고 도중에 멈춰 있어, 매우 당혹스럽다.
- 터미널이 (rebase ~ 1/6) 과 같은 메세지로 rebase가 진행중임을 알려주니 겁먹지 않도록 하자!
- 충돌은 충돌일 뿐, 해당하는 코드를 수정 후
- Git add .
- (Git commit은 하지 않는다. 수정 사항이 없으니까)
- Git rebase ㅡㅡcontinue를 진행한다
- 멈춰 있던 리베이스가 진행된다.
- 충돌이 여러번 나면 그 때마다 충돌을 해결하고 git add . / git rebase ㅡㅡcontinue를 반복한다.
- 계속 해결이 안된다면, git rebase ㅡㅡabort로 아예 rebase를 진행하기 전 상황으로 돌아갈 수도 있다.
'프론트엔드 개발자가 될거야. > git' 카테고리의 다른 글
git clone시 git flow이해하기 (0) 2022.07.10 Git 명령어 정리 (0) 2022.06.13