rebase
Git flow
main
개발이 합쳐져서 배포하는 곳
develop
배포되기 전 상태 QA과정. (실제사용해보면서 버그잡는 과정)
feature
각 브랜치
release
배포
hotfix branch
배포 후, 수정해서 다시 배포
branch 병합하는 Merge / Rebase
merge
메인 → feature/sign-up, feature/sign-in → merge는 커밋했던 시점 그대로 가져옴 → merge commit이 생김.
단점:
무의미한 merge이 생겨 branch history가 지저분해지고, 독립된 브랜치에서 로직 하나를 작성하고 수정하더라도, 다른작업과 겹쳐 구분하기가 어려워져 history가 복잡하다고 표현한다.
PR을 통해 프로젝트의 내역을 확인 할 수가 있다.
rebase 명령어를 사용하여 불필요한 커밋을 squash 할 수 있다.
git merge 하지말고 git rebase 로 병합하기.
rebase하면서 여러커밋을 한꺼번에 합치는 squash를 사용 할 수 있고, 브랜치를 합쳐야 하는 상황이 아이어도 git revase -i main 명령어를 통해 브랜치에 쌓인 커밋을 하나로 정리하기
!!!!!! 정상적인 경우 PR/ branch 당 커밋이 하나여야 한다 !!!!!
rebase 도중 충돌이 일어날 경우 코드가 날아간 거처럼 보일 수 있는데 합치던 중 중단된 것.
충돌을 해결하고 남은과정을 끝까지 진행 하면 모든 코드가 다들어와있다.
conflict는 commit과 commit 사이에서 일어나는 작업 내용 사이의 충돌이므로,
커밋이 쌓이기 전에 squash 해야한다.
혹 잘못 리베이스를 했다면,
git rebase —-abort (리베이스 도중) 혹은 git reflog 로 돌아갈 지점을 찾은 후 git reset --hard 돌아갈지점 (리베이스 완료 후) 명령어로 복구할 수 있다
git add . → git rebase -—continue
rebase만 하면 커밋history 다 있는데, squash 하면은 커밋 history가 다 사라짐.
취소하면은 rebase 전으로 돌아감.
커밋메세지를 제대로 남겨두어야 돌아갈 시점을 정확히 알 수 있음.
rebase 명령어 순서
커밋 확인 후, 내 브랜치에서
git rebase -i master (squash, 커밋을 하나로 만들 때)
첫번째 pick 만 남겨두고 s로 바꾼다. →저장 → multi line commit 작성여기서 squash 가 된 상태...
conflict 발생할 수 있음.
그러면 여기서 또 컨플릭트 해결하고, 마지막까지 conflict 확인 후, pushpush 후 PR 작성하면 conflict 생김
git pull origin main → git checkout feature/seyeon25 → git rebase -i master (브랜치 병합할 때도 쓰임)
충돌해결 후git add . → git rebase —continue
커밋수정하는 부분으로 넘어 감.
마지막으로 확인하기
git log or git status (만약에 rebase) 더 안뜨면 push.
git push origin feature/seyeon25 → 오류
이유는 : rebase를 해서 로컬이 가지고 있는 히스토리가 다르기 때문에git push origin feature/seyeon25 -f (강제푸쉬)
🙋🏻♀️Today,
아직도 무서운 Git....
특히 팀프로젝트 할 때는 손이 덜덜 떨린다. 혹시라도 실수하거나 할까봐 걱정이 많았다.
그래도 나름 열심히 커밋을 남겼다.
그 덕에 진짜 캐러셀 오류떴을 때 많은 도움됐다ㅠㅠㅠㅠ
커밋짱짱맨...😭👏👏
