3/2 목 (Git Rebase 조사중) TIL

(최종 프로젝트 진행중)

오늘은 팀원들과 수시로 상의 및 회의를 하고, 기본 프로젝트 뼈대를 만들며 깃허브와 (단체로) 씨름하고, 또 git의 rebase 방법을 쓰면 좋을 것 같아서 조사하였다.

(여기 참고함)

Git - Rebase 하기

https://git-scm.com/book/ko/v2/Git-브랜치-Rebase-하기

---

※ 이하는 스스로 공부하며 적어둔 노트이며 불확실한 내용이 있을 수 있습니다. 학습용으로 적합하지 않음을 유념해주세요. ※

병합충돌을 적게 가져가는 방법: Rebase

• 배운 방법을 일단 적어두었다. 에러가 많이 나서 살펴보는 중.

  1. 현재 로컬의 로그인(가칭) 브랜치에서 작업중일때, 현 작업상태를 로그인 브랜치에 커밋한다.

  2. git checkout origin/main <- 원격브랜치로 이동

     git checkout -b fix-failing-tests origin/fix-failing-tests
     이 명령어를 다음과 같은 세 동작이 실행됩니다.
     
     fix-failing-tests라는 새 브랜치를 생성하고,
     새 브랜치로 체크아웃이 되며,
     origin/fix-falling-tests의 변경이력을 새 브랜치로 가져옵니다.

     -b : 브랜치 생성

     PS C:\Users\USER\Desktop\Sparta\04.4_nest_practice_testest> git branch -a
     * (HEAD detached at origin/main)
       master
       remotes/origin/main

  3. git pull origin main <- 원격브랜치의 내용을 가져온다

     PS C:\Users\USER\Desktop\Sparta\04.4_nest_practice_testest> git pull origin main
     From https://github.com/devocean-han/sparta-typescript-practice
      * branch            main       -> FETCH_HEAD
     Already up to date.

     ⇒ 어차피 FETCH_HEAD로 가져오는데…?

  4. git checkout login <- 로컬브랜치로 다시 되돌아 온다

  5. git rebase main <- 원격 브랜치에서 생성된 작업 히스토리를 재배치 한다.

     PS C:\Users\USER\Desktop\Sparta\04.4_nest_practice_testest> git rebase main
     fatal: invalid upstream 'main'

     ⇒ 에러 뜨는데..?

  6. git log <- 0번에서 했던 커밋을 찾고, 그 바로 밑의 커밋의 해시값을 찾아 복사한다

  7. git reset 해시값 <- 여기까지 하면 파일들이 원격브랜치에 맞춰 최신화 되면서 내 작업내용도 남아있다.

  8. git status <- 수정한 파일들 확인

  9. git add -p <- 수정한 내역들 확인하며 스테이징하기

  10. git push <- 원격 레포에 로컬이랑 동일한 이름의 브랜치가 없다면 여기서 업스트림 생성하라고 메시지 뜸.

  11. 깃헙 홈페이지 가서 원격 메인브랜치에 풀 리퀘스트를 하고, 코드리뷰 후 머지하기.

위의 1 ~ 10번 과정을 조금 더 정리해보면 이렇다 :

⇒ 로컬에 main과 test 브랜치가 있는데, test에 main의 새 커밋을 반영하고 싶다. 현재 내 test에도 변경사항이 있다.

1. test에서 작업하던 것을 임시로 ‘wip’이라고 커밋해 놓는다.

2. 로컬 main으로 스위칭하여, 원격의 main을 로컬 main으로 pull 해온다.

3. 다시 로컬 test로 스위칭하고 git rebase main 명령을 내린다.

큰 흐름은 이렇고, 이를 git 명령어로 나타내면 이렇다:

git commit -m “wip”

git checkout main

git pull 

git checkout test

git rebase main

여기서부터 애로사항이 생기는데…

• 병합 충돌이 일어나는 것을 일일이 수작업으로 충돌 해결할 거였으면 그냥 merge랑 뭐가 다르지?

• rebase --continue를 몇 번이나 시키는 건지… 순서도 안 맞는 것 같다.

아무튼 어떻게든 해서 rebase를 완료하고 나면, 다음과 같은 방법으로 이전에 ‘작업하다 임시로 커밋 해놓은 작업물’을 다시 불러와서 작업할 수 있다:

git reset (-mixed) {’wip’ 직전 커밋 해시}

// 하던 작업 다 마치고 커밋하고서 이제 원격의 test 브랜치에
git push

---

3/3 금 업데이트

위의 애로사항에 대한 해답 (그리고 다시 의문들) :

⇒ 브랜치 둘의 충돌이 일어나는 부분을 해결할 때, 가장 오래된 커밋부터 commit by commit으로 비교하고 충돌을 해결하도록 유도한다. 이 기능이 오히려 안전한 merge를 보장하는 셈.

• 메인 스트림이 되는 브랜치(main)의 ‘최신 커밋’과, 낑겨 들어가려는 브랜치(test)의 ‘분기 시점부터의 커밋들’을 비교하는 건가?

  [main]최신 커밋 —비교— [test]main과의 마지막 공통 로그 + 1커밋

  [main]최신 커밋 —비교— [test]main과의 마지막 공통 로그 + 2커밋

  [main]최신 커밋 —비교— [test]main과의 마지막 공통 로그 + 3커밋

  …

  이런 식으로?

⇒ rebase —continue를 할 때마다 작성(수정)해 넣는 커밋 메세지는, 기존의 커밋 해시를 아예 지우고 새 커밋이 된다. 그래서 rebase를 이름하야 ‘커밋 히스토리 조작’이라고도 부르는 것. 이 때 삭제 및 수정 대상이 되는 ‘기존의 커밋’은 ‘합류하려고 하는 브랜치’쪽, 즉 main과 test 중 test 브랜치의 커밋임.

• ⇒ 확인 필요.

⇒ 아무튼 그래서 rebase 도중 충돌 해결이 필요했던 커밋들이 최종 커밋 로그의 가장 위쪽에 쌓여서(=로그 재배치=히스토리 조작) 나타나게 된다.

Uploaded by N2T