작업 중간에 원격 저장소 pull을 받는 올바른 방법

 

https://meoweundi.tistory.com/20

remote에 push한 커밋은 rebase 하시면 안됩니다(꼬인 git 푼 기록)

 

위 글에서 가졌던 의문의 올바른 해답을 찾았다.

 

👩🏻‍💻 문제 상황 정의

로컬 브랜치를 local/[브랜치명], 원격 저장소의 브랜치를 remote/[브랜치명]으로 지칭하겠다.

local/feature 브랜치에서 작업 중이고, remote/feature 브랜치에 커밋을 push한 적이 있는 상태. 그러나 아직 기능 개발이 진행 중인 상황. 이 상황에서 remote/main 브랜치의 변경 사항을 pull 받아와야 한다.

(ex 다른 동료가 작업하던 브랜치가 메인 브랜치에 merge되어 이를 내 코드에도 반영해야 하는 상황)

 

 

✅ 해결 방법

1. git checkout [브랜치명]
2. git fetch origin
3. git diff origin
4. git merge origin/main
5. merge에 대한 commit을 수정할 수 있는 vim 창이 뜬다. commit 메시지 수정 후 :q! 로 저장한다.(메시지 수정은 생략 가능)

단계별 상세한 설명은 다음과 같다.

 

1. pull 받을 브랜치로 이동
2. 원격저장소의 작업 내역을 로컬저장소에 가져온다.
3. 원격저장소의 작업 내역과 로컬저장소의 작업 내역을 비교한다.
4. 원격저장소의 main브랜치와 로컬저장소의 현재 브랜치를 merge한다.
5. merge는 새로운 commit을 생성한다. 해당 커밋의 커밋 메시지를 작성하는 것이다. 보통 커밋 메시지를 작성할 때에는 git commit -m "my msg 라는 명령어를 통해 작성하는데, 이때에는 메시지를 작성할 수 있는 에디터창이 뜬다. 해당 에디터창 안에서 메시지를 작성해주면 된다. 

 

해결법이 궁금했다면 여기까지만 읽으시면 됩니다!

 

 

 

☝🏻 pull 대신 fetch-merge를 쓰는 이유

fetch와 merge를 한 번에 할 수 있는 명령어가 있다. 바로 pull이다.

 

pull을 바로 쓸 수 없는 이유는 현재 로컬 브랜치와 원격저장소의 브랜치가 fast-forward 관계가 아니기 때문이다. (두 브랜치 모두 각자의 새로운 커밋을 가지고 있으니까) 

 

원격 브랜치와 로컬 브랜치가 fast-forward 관계일 때만 pull이 가능하도록 설정해 놓았기 때문에, 현재 상황에서 pull을 하면 pull이 중단된다. (Not possible to fast-forward, aborting → 이런 에러 메시지가 뜬다.) 따라서 fetch와 merge를 각각 진행해 주어야 한다.

 

 

✌🏻 rebase와의 차이점

이전 글에서는 원격저장소의 작업을 로컬 브랜치에 내려받기 위해 rebase를 사용했다. 그 결과 로컬브랜치 커밋들의 복사본이 생겨났다(!) 나는 이게 내가 rebase를 잘못 사용해서 생기는 문제점인 줄 알았는데, rebase 자체의 특성이었다. 

‣ rebase 이해하기

rebase는 브랜치가 분기되는 커밋을 다른 커밋으로 이동 시킨다. 그림으로 설명하자면 다음과 같다.

 

위 그림에서 feature 브랜치는 커밋 C2에서 분기되었다. 이때 feature 브랜치에서, main 브랜치에 대해 rebase를 하면?

---

짜잔 분기점 커밋이 C2에서 C3으로 변경됐다. 그렇다면 이렇게 분기점 커밋을 이동 시키는 이유는 뭘까?

---

위 그림과 동일한 그림이다. 한 줄로 정렬했을 뿐이다.

바로 이렇게, 커밋 히스토리를 한 줄로 관리할 수 있기 때문이다. 동일한 작업을 rebase가 아닌 merge를 사용해서 할 경우 다음과 같은 그림이 될 것이다.

---

확실히 rebase를 사용했을 때의 git 히스토리가 좀 더 깔끔한 것을 확인할 수 있다.

 

‣ rebase의 문제점

위 그림을 잘 보면, rebase 그림에서 C4, C5, C6에 따옴표 표시가 되어있는 것을 확인할 수 있다. C4, C5, C6의 복사본이라는 의미이다.

 

즉 rebase는 기존의 커밋을 그대로 사용하는 게 아니라, 같은 내용의 다른 커밋을 새로 만든다. 정확히는 "feature 브랜치의 기존 커밋에 main 브랜치와의 차이점이 반영된" 커밋들을 만들어 낸다. (차이점이 없다면 그냥 복사본이 생성되고, 차이점이 있다면 반영된다.)

파란색 라인과 초록색 라인에서 같은 내용-다른 커밋아이디의 커밋들을 확인할 수 있다.

그 결과 위 그림처럼 동일한 내용의 커밋이 두 개씩 생성된다.

 

---

git 히스토리를 한 줄로 관리할 수 있다는 장점이 있기도 하고 위 그림처럼 동일 내용의 커밋이 여러 개 생기는 게 문제가 되지 않을 수도 있다. 하지만 아직 git을 배워나가는 입장인 만큼 merge를 사용한 방식에 먼저 익숙해지고자 한다.