git rebase✌🏼✌🏼

Jung Hyun Kim·2020년 7월 9일

git

목록 보기

4/6

git rebase 💨

내 깃 커밋의 blocker... git rebase 무서운 너란녀석.....하지만 쓰는데는 다 이유가 있다.. 열심히 알아가 보자! 🙋🏼‍♂️

git rebase 나 git merge 나 결국 우리의 목적은 로컬 브랜치에서 작업하던 결과물을 마스터 브랜치로 합치는 것인데, 그 방법을 어떻게 할 것이냐의 차이이다.
git merge를 사용해서 많은 개발자들이 한 프로젝트를 작업한다면 그 branch들은 messy branch history의 끝판왕이 될 것이다!
이런 복잡한 브랜치 구조는 , 나중에 개발자들이 history를 파악해 나갈 때, 하나하나 문제를 track down 해나가기도 복잡하기에 이러한 문제를 해결 할 방법이 git rebase를 사용하는 것이다.

아래 그림 처럼, 전체 feature branch를 master 로 옮기는 형태라고 생각하면 된다.
-merge commit이 아니라 master를 rebase 시작점을 바꾼다 라는 의미이다.
git rebase를 통해 훨씬 깔끔한 project history 관리가 가능하고, 불필요한 merge commit을 없앨 수 있다.
git flow가 timeline 처럼 한 줄로 관리가 되기 때문에 history trace가 편하다.

여기까지는 merge나 rebase나 과정은 똑같다 이 이후부터가 중.요!

-i —vim을 켜서 실행한다는 뜻

commit 목록 중 제일 상단 commit, 선택하려는 commit을 p(pick) 나머지를 s(squash)로 지정

11.1 successfully rebased and updated 가 뜨면 git push origin feature/main

11.2 conflict가 뜨면 conflict 수정후

git add .
git rebase --continue

해결 될때 까지 무한 반복 git add . git rebase --continue

수정하고 successfully rebased and updated 가 뜨면 git push origin feature/main
만약 현재 master가 그사이 업데이트 되었다면, 7번 부터 다시 실행 해야 하는데,이 때 다시 진행하면 rejected 가 되면 git push origin feature/main -f force push 한다
그 후 github에 가서 Pull Request 작성

(혹시나 잘못된 정보가 있으면 말씀 부탁드립니다 (깃생아 ㅜㅜ))

결국 둘의 차이는 내가 중 점을 어디에 둘 것이냐 이다.
"나는 모든 commit이 해당 프로젝트를 만들기 위한 history였기 때문에 history를 revise하는 것은 허용 못해!" 그 branch history가 messy 한 것 또한 It is what it is! 라면 git merge
"아니! 내가 프로젝트 결과물에 하나 하나 draft의 내용들을 어떻게 수정한 것 까지 남겨야해? 난 정렬 된 깔끔한 과정을 남기고 싶어!" 라면 git rebase

코린이 프론트엔드 개발자💻💛🤙🏼