(Git) rebase 사용법 (상세 설명) / rebase와 merge의 차이점 / rebase사용 이유 / github에서 rebase 사용하기

포스팅 목차

1. rebase와 merge의 차이점

2. rebase와 merge의 장단점

3. rebase 사용 방법 (github를 통한 사용법, 상세하게)

4. rebase에 대한 개인적인 생각

---

1. rebase와 merge의 차이점

주의 : rebase 후의 b1과 b2의 commit은 original b1, b2 브랜치의 커밋에서 복제해온 커밋이다.

즉 rebase 전의 b1, b2 커밋과, rebase 후의 b1, b2 커밋은 다르다.

 

---

2. rebase와 merge의 장단점

rebase 장점

1) 한 사람이 코드를 작성한 것과 같은 git graph를 볼 수 있다. (git graph가 깔끔하기 때문에 )

> git graph가 깔끔하면, commit이력을 한눈에 보기 쉬워진다.

2) base 브랜치의(보통 main 브랜치) 업데이트 사항을 바로바로 공유받을 수 있다.

3) 병합 커밋이 없다. ( merge시 생기는 커밋)

 

rebase 단점

1) 다른 브랜치에서 작업할때, base로 정한 브랜치가 변경되면, 작업 중인 브랜치의 base도 같이 변경해줘야 된다.

예시) 작업중인 브랜치 : b1, 베이스로 정한 브랜치 : main , main 브랜치가 수정되었을 경우.

$ git switch main    // main 브랜치로 전환
$ git pull main    // 로컬에서 main 브랜치 업데이트
$ git switch b1    // 작업중인 브랜치로 전환
$ git rebase main    // 작업중인 브랜치의 base를 main으로 바꿔줌

2) 브랜치 커밋 이력을 한 눈에 보기는 어렵다.

3) merge보다 사용하기에 더 어려운 부분이 있다. 잘 이해하지 못하고 사용하는 경우 코드가 꼬이는 상황이 더 발생하기 쉽다.

 

merge 사용 장점

1) 모든 브랜치의 커밋 이력을 보기 쉽다.

 

merge 사용 단점

1) branch가 많아질 수록 commit 이력을 한 눈에 보기 어려워진다.

(위 사진에서 브랜치 2개밖에 없는데도 rebase보다 보기가 어렵다는 것을 알 수 있다.)

2) merge 커밋이 생겨 불필요한 기록이 생긴다.

---

3. rebase 사용 방법 (github를 통한 사용법, 상세하게)

1번 부터 6번 까지는 rebase하는 기본적인 방법과 github에서 어떻게 rebase하여 코드를 저장하는지 알 수 있다.

7번 부터 마지막 까지는 rebase conflict 날 때 해결법을 볼 수 있다.

 

1) 기본 세팅 : 

1-1 ) visual studio의 extensions에서 git graph 설치

1-2 ) github에서 repository 추가 > 원하는 폴더에 clone 해오기

 

2) main branch에서 index.html파일 추가 및 push

// index.html파일 추가 후
$ git add .
$ git commit -m"main commit"
$ git push

 

3) branch1브랜치 추가 및 branch1로 전환, home.html파일 추가 후 push

$ git add .
$ git commit -m"branch1 commit"
$ git push --set-upstream origin branch1

 

4) github에서 push한 branch1을 main에 rebase&merge 시켜주기

github에서 create a merge commit이 아니라 아래 사진의 빨간 박스에 쳐진곳

"rebase and merge"를 클릭해준다

 

 

5) main으로 전환 후, pull 해온다.

$ git switch main
$ git pull

 

 

6) git grah 클릭 시 아래와 같은 화면을 볼 수 있다.

(git Graph는 visual studio 하단 왼쪽에 "git Graph"라고 쓰여있는 곳 클릭하면 된다!)

branch1 commit이 main branch에 삽입됐다.

(분홍색 가지는 branch1을 삭제하면 없앨 수 있음.)

 

7) branch2 브랜치 생성 및 파일 수정 및 commit 까지만

// 파일 아무거나 수정 후 
$ git switch -c branch2
$ git add .
$ git commit -m"branch2 commit"

 

 

8) branch3 브랜치 생성 및 파일 수정 및 push

// 아무 파일 수정 or 생성
$ git switch main
$ git switch -c branch3
$ git add .
$ git commit -m"branch3 commit"
$ git push --set-upstream origin branch3

 

9) github에서 branch1과 마찬가지로 rebase and merge를 해준다.

 

10) branch3는 이제 필요 없어졌으므로 delete branch를 한다. (branch1도 delete 해준다.)

 

11) main 에서 pull

아래와 같은 모양의 git graph를 볼 수 있다. main branch에 branch3의 커밋도 삽입됐다.

$ git switch main
$ git pull

 

12) branch2로 돌아와서 main에 변경 사항이 있으므로 main의 base로 변경하는 작업을 해주자. (즉, branch2를 rebase 해주자.)

그러면 아래 이미지와 같이 conflict가 난다.

(conflict 나는 파일은 빨간색으로 표시된다. )

$ git switch branch2
$ git rebase main

 

13) 빨간색으로 표시된 파일에 들어가서 충돌을 해결해주자.

그리고 수정된 파일을 add 해준 다음 rebase를 계속 진행한다.

// conflict 해결 후
$ git add .
$ git rebase --continue

 

14) commit 내용을 수정할 수 있는 vi 편집창이 나타난다.

vi 창에 관련된 상세한 내용이 궁금하다면 해당 블로그에 정리가 잘 되어있으니 참고하면 좋을것 같습니다. 

https://blockdmask.tistory.com/25

" :wq " 를 사용해서 (저장하고 나가기) 편집창을 나가준다.

:wq

 

 

15) branch2도 push 해준다

push가 잘 되면 상관없지만,

rebase 를 하고 난 후 push error가 있 을경우 push --force를 통해서 강제로 덮어씌워줘야 된다..

(강제 push는 git push origin 브랜치명 --force)

 

지금은 push error가 안나니까 아래와 같은 명령어를 사용해 주면 된다.

(이미 upstream 되어있는 경우는 git push 만 작성해줘도 됨.)

$ git push --set-upstream origin branch2

 

 

16) 마찬가지로 rebase and merge를 진행시키고 branch2도 필요없어 졌으니 delete한다.

 

 

17) main에서 pull 해온다

$ git switch main
$ git pull

 

 

18) git graph 화면

 

19) github 에서 필요없어진 branch를 다 삭제 했다면 

삭제된 상태를 업데이트 해준다.

 

원격 저장소에 유효하지 않는 브랜치 삭제.

$ git fetch --prune

 

그리고 local에 남아 있는 쓸모 없는 branch들도 지워준다.

// local과 원격 저장소의 모든 브랜치 목록
$ git branch -a

// 쓸모 없는 branch가 local에 남아 있을 경우\
$ git branch -d 브랜치명

// 위 명령어로 삭제가 안 될 경우
$ git branch -D 브랜치명

 

 

20) 위 과정을 다 거친 후, 보이는 git graph의 모습

하나의 가지로 통일 된 모습을 볼 수 있다.

 

---

4. rebase에 대한 개인적인 생각

rebase에 대해 여러 문서들을 참조하며 학습해봤지만, 아직 완변하게 이해하지는 못했다.

확실히 merge보다 rebase 라는 개념이 더 어려운 것 같다.

 

git을 처음 사용하는 분들한테는 추천하지 않고,

"merge가 더 좋다", "rebase가 더 좋다" 보다는

자신의 프로젝트와 협업할 팀원들의 스타일에 맞게 선택하면 될 것 같다.

 

참고 자료

git rebase에 대해서 - git 공식 문서

Git - Rebase 하기

 

 

git rebase 흐름 간단 설명 - majaeh43님 velog

GIT flow & GIT rebase 🎃

 

rebase의 위험성 - 까망 하르망님 Tistory

[Git 깃] git rebase 위험성

 

git rebase와 conflict 해결법 - sw developer님 github blog

[Git] Rebase와 Conflict 해결 방법 - SW Developer