[팀 프로젝트] 프로젝트하면서 Git과 친해지기 - 4 (git pull로 원격저장소 브랜치 가져오기)

현 상황에 대해 설명하겠다.

GItFlow 방식을 사용하기 위해 feature 별로 브랜치를 파서 개발하기로 했다. - 깃린이인 나는 feature 별로 브랜치를 파야했다.

feature 별로 각자 개발하고 develop에 merge해 소스코드 버전을 높히는 식이 GitFlow 방식이다.

 

깃린이인 나는 브랜치를 하나만 파서 가지고 노는 수준밖에? 안되었기에,...ㅋㅋㅋㅋㅋㅋ
git으로 여러 브랜치를 파서 진행하는 건 나에겐 진짜 큰 장벽이었다 ㅋㅋ...
그래도 책임감있게 프로젝트에 임하고 싶어서 git을 어떻게든 극복하자고 마음먹고 git을 쓰기 시작했다.

 

아무튼 오늘 겪었던 git 사용일화에 대해 설명하겠다.

빙글님께서 organization의 repository에 이전에 파둔 develop 브랜치를 업데이트 해주셨다.

그래서 로컬 저장소의 develop 브랜치를 원격 저장소의 develop 브랜치를 가져와

업데이트 해야되는 상황이다.

 

---

원격 저장소 branch의 소스코드 git pull 명령으로 가져오기

아래 명령으로 원격 저장소의 develop 브랜치의 소스코드 내역을 가져왔다.

(git checkout develop 명령으로 develop 브랜치로 이동한 상태)

$ git remote update
# 원격 저장소 정보 업데이트

$ git pull upstream develop

 

$ git pull upstream develop 명령 수행결과

자 그럼, pull 성공했으니 로컬 저장소의 develop 브랜치에 원격저장소 소스코드가 가져왔겠지?

답은 아니다,,,ㅋㅋ

 

pull 이 성공했다는 메세지가 떴는데도 로컬 저장소 develop 브랜치에 가져온 내역이 저장되지 않은 걸까?

깃린이로써,,, 원격저장소에서 가져온 코드파일이 증발한 듯한 감정이었다 ㅋㅋ...

그래서 증발한? 코드파일이 어딧는지 혼자 계속 찾았다.. - 그러면서 git에 대해 깊게 알아갔음. -> 프로젝트하면서 Git과 친해지기 - 3

 

해결 시작

이에 대한 답은 터미널로 요리조리 많지고, 수많은 구글링끝에 답을 찾았다..

중간중간에 터미널로 요리조리 만지다가 git에 대해 새롭게 알게된 것도 있다 ㅋㅋㅋ -> 이건 프로젝트하면서 Git과 친해지기 - 3

 

증발한? 원격 저장소의 브랜치 소스코드들은 FETCH_HEAD 가 가지고 있었다.

명백히는 가져온 소스코드 커밋을 포인터로 가르키고 있는 것

 

이는 아래 명령을 똑같이 수행해보자

$ git checkout develop
# develop 브랜치로 이동

$ git pull upstream develop
# 원격저장소의 develop 브랜치의 코드파일을 가져옴

 

그리고 $ git branch 를 통해

로컬 저장소의 branch가 어떤 것들이 있는 지 확인하면?

$ git branch 명령 수행결과

분명히 develop 브랜치에서 git pull을 했는데

현재 FETCH_HEAD 라는 곳에 위치해 있다.

 

또한,

로컬 디렉토리를 보면 원격 저장소 브랜치 코드파일이 가져와 있는 걸 확인할 수 있다.

진짜 머지? 머야? git의 논리가 도저히 이해가 안됐음.. 그래서 멘붕까지 왔었다. - 그래도 책임감 있는 사람이 되려고 끝까지 함 ㅎㅎ

 

정리하면, 로컬저장소의 develop 브랜치에서 git pull을 했는데,
develop 브랜치에 git pull 내역이 가져와지지 않고
FETCH_HEAD 라는 곳에 git pull 내역이 가져와진 상태이다.

 

그래서 난,

여기서부터 내 힘으로는 도저히 이해할 수 없다고 생각해

Nest.js 오픈 채팅방에 질문해 해결했다.

 

git pull 명령을 사용하면 HEAD가 pull에 지정한 원격저장소의 브랜치의

소스코드 커밋을 포인터로 가르키고 있게 된다.

 

그래서 아까 git branch 수행결과에서 HEAD가 pull로 가져온
소스코드 커밋을 가르키고 있었던 상황이었다.

즉, git pull을 수행 시 HEAD가 가져온 코드파일 커밋을 가르키게 된다.

HEAD는 일회용 공간으로 다른 브랜치에서 git pull을 수행 시 다른 코드파일 커밋을 가르킨다.

 

이제 증발된? 원격저장소 코드파일의 근황을 알게 되었으니

로컬 저장소의 브랜치에 가져오는 방법은 무엇일까?

 

내가 한 방법은 개발 후반 부에서는 비효율적이긴 하다. - 이거 정리하고 merge 방법으로 브랜치 병합을 시도해보겠다.

참고만 하자 -> 안되면 이걸로 하기 ㅎㅋㅎㅋ

# git checkout FETCH_HEAD를 수행해 둔 상태
$ git checkout -b develop
# HEAD가 가르키는 커밋을 develop 브랜치를 새로 만들고 가져온다.

 

develop 브랜치에 코드파일이 가져와짐

드뎌 성공.. 원격저장소 코드 특정 브랜치로 가져오기..

 

아래 블로그를 참조해 git pull 수행 시 발발되는 Detached HEAD에 대해 알게됨.

[Git/번역] Detached HEAD

 

 

---

해결하고 혼자 추가 추론 (브랜치를 만들지 말고 병합해서 코드내역 업데이트하기)

원격저장소 코드 업데이트 내역을 특정 브랜치로 반영하는 방법을 터득했다.

그치만, 내가 한 방법은 초기 개발에서 덮어쓰기와 같은 원리로

기존 로컬 저장소 브랜치 코드파일을 삭제하고 가져온 코드파일을 추가한 것이다.

 

git을 어느정도 다뤄본 입장에서 이와 같은 방법은

기존에 있는 개발버전을 삭제하고 뉴버전을 저장하기에

업데이트가 아닌, 처음 개발버전으로 시작한다고 볼 수 있다.

그렇기에 이와같은 방법은 git을 사용하는 논리에 어긋난다고 생각했다.

쉽게 설명하면,
내가 로컬 저장소에서 1.4.2를 개발하고 있다고 가정하자
함께 프젝을 하는 팀원이 1.4.2-feature1 를 개발완료해 organization repository에
1.4.2-feature 버전을 push했다고 가정하자
여기서 난 1.4.2-feature를 가져와 feature에 해당하는 코드를 가져다 쓰고싶다.
그럼, 여기서 난 1.4.2-feature1 코드파일을 새로 저장하고 내가 개발 중인 1.4.2-feature2 코드를 추가해야 되나?
이렇게 하면 이전에 작성해둔 코드를 또 작성해야하기에 번거롭다.
그래서 난 원격 저장소의 소스코드를 가져와 내가 개발 중인 1.4.2-feature2와 합쳐서
1.4.2-feature3로 이어서 개발을 시작하면 편하다.

이와 같은 논리에 의해 git을 사용하는 것이다. - 개발의 효율 극대화
글고, 합치는 논리는 git에서 알아서 처리해주는 것이고
이에 따라 git 사용 시 충돌이라는 개념이 생겨난 것이다. - 충돌 해결 방법만 잘 습득하면 깃스터 가능! 

 

그럼, 나도 merge 개념을 이용해 굳이 새로 만드는 것보다

기존에 것에 업데이트하는 방법을 찾아보겠다.

 

merge용 브랜치를 생성해서 가져온 코드파일과 기존의 코드파일을 병합한다.

 

아래 명령을 수행하면, HEAD가 원격 저장소의 develop 브랜치 코드파일 커밋을 포인터로 가르킨다.

$ git pull upstream develop

 

그래서 첨엔 HEAD를 브랜치로 생각하고, 로컬 저장소의 develop 브랜치로 가서

$ git merge FETCH_HEAD 명령을 했다. -> 결과는 안됨

HEAD가 포인터로 가르키고만 있기에 수정해도 반영이 안됨

 

HEAD가 커밋을 가르키기만 하고 새로운 브랜치를 생성해서 커밋을 넘겨주는 게 HEAD의 역할이다.

그럼, merge용 브랜치를 생성해서 여기에 가져온 코드파일을 넣어두고

이 브랜치(merge용 브랜치)와 로컬저장소의 브랜치를 merge를 했다.

 

결과는? 원하는 대로 기존의 코드파일과 가져온 코드파일을 병합할 수 있었다.

 

개발 블로그 식으로 작성해보겠다. - 이해가 잘 되기 위함.

 

# 원격저장소에서 가져온 코드파일 커밋을 가르키고 있는 FETCH_HEAD로 이동
$ git checkout FETCH_HEAD

 

merge를 위한 브랜치 생성!

# merge용 브랜치 생성
$ git checkout -b develop1

 

기존에 개발하고 있는 브랜치로 이동해 merge를 준비한다.

# 로컬저장소의 개발 중인(develop) 브랜치로 이동
$ git checkout develop

 

merge 수행

# develop 브랜치와 develop1 브랜치를 merge함
$ git merge develop1

 

결과는?

merge 수행결과

read.md 가 테스트를 위해 추가로 생성해 둔 파일 (충돌이 없게 셋팅함 ㅎㅋㅎㅋ)

성공적으로 기존의 브랜치와 원격저장소의 브랜치를 병합할 수 있었다.

 

 

느낀점과 개인적인 사담

배움의 속도는 경험과 비례하다고 생각하는 계기가 되었다.

배움의 속도가 느린 것은 그만큼 경험이 없어서 어떻게 배워야하는지 감이 안잡힌다.

그렇기에, 많은 것을 배우면서 자신의 학습 속도를 늘릴 수 있는 경험을 쌓아가는 과정이 중요하다는 사실을 느꼈다.

 

그럼, 내가 할 수 있는 건 지식을 습득하는 게 느리다고 위축될 필요없이 나의 학습 경험을

꾸준히 쌓아가야된다 라는 생각을 가져야 됨을 성찰할 수 있었다.

 

학습 경험이 쌓여서 어떻게 배울지 스스로 판단이 가능해진다.