티스토리 뷰

용어 정리

* 리모트 Refs : 리모트 저장소에 있는 포인터 레퍼런스

 

$ git ls-remote : 리모트 Refs 조회

리모트 Refs 대신 보통 리모트 트래킹 브랜치를 이용한다.

 

* 리모트 트래킹 브랜치 = 리모트 브랜치를 추적하는 레퍼런스이자 브랜치. 로컬에 있지만 임의로 움직일 수 없다. 리모트 서버에 연결할 때마다 리모트의 브랜치 업데이트 내용에 따라 자동으로 갱신된다.

<remote>/<branch>형식.

 


예제를 통해 자세히 알아보자.

 

 git.ourcompany.com 이라는 Git 서버가 있다.

 

로컬에 clone해온 서버의 저장소는  origin 이라고 한다.

 

origin 으로부터 저장소 데이터를 모두 내려받고 master 브랜치를 가리키는 포인터(=origin/master)를 만든다. 이 포인터는 맘대로 변경할 수 없다.

그리고 Git은 로컬의 master 브랜치가 origin/master 를 가리키게 한다. 이제 내 로컬의 master 브랜치에서 작업을 시작할 수 있다.

로컬에 clone한 이후 서버와 로컬의 master 브랜치

 

로컬에서 작업을 하고 있는데 다른 팀원이 git.company.com 서버에 push하여 master 브랜치에 변경사항이 생긴다면?

그러면 팀원과 나의 히스토리는 달라지게 된다.

그러나 서버 저장소와 데이터를 주고 받지 않았기 때문에 나의 로컬은 변함이 없다. 즉 origin/master 포인터는 그대로다.

로컬과 서버의 히스토리는 독립적이다.

 

$ git fetch origin : 리모트 브랜치(회사 서버)의 내용을 로컬에 가져와서 동기화.

위 명령을 실행하면 origin(서버주소-git.ourcompany.com)을 찾아서, 로컬엔 없는 새로운 데이터를 모두 내려받고, 로컬 저장소에 업데이트한 다음, origin/master 포인터를 최신 커밋으로 이동시킨다. 

$ git fetch origin 명령으로 리모트 브랜치 정보 업데이트(동기화)

 

이번엔 리모트 저장소를 여러 개 운영하는 상황을 보자. 회사에서는 빈번한 일이다.

 

저장소 주소가 git.team1.ourcompany.com 인 서버가 있다고 하자. 

이 글에서 지난 번에 공부했던 것처럼 git remote add 명령으로 teamone이라는 이름으로 새 저장소를 추가한다. 

$ git remote add teamone git://git.team1.ourcompany.com

서버를 리모트 저장소에 추가(git remote add)

 

 

서버를 추가하고 나면 $ git fetch teamone 명령으로 teamone 서버의 내용을 로컬로 내려받는다. 

이때 teamone 서버의 데이터는 모두 origin 서버에 있는 내용이라 데이터의 변화는 없다.

그러나 여기서 생긴 결정적인 변화는!

리모트 트래킹 브랜치 teamone/masterteamone 서버의 master브랜치가 가리키는 커밋을 가리키게 되는 것이다.

teamone/master의 리모트 트래킹 브랜치

 

 

 

Push하기

$ git push <remote> <branch>

$ git push origin serverfix
Counting objects: 24, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done.
Total 24 (delta 2), reused 0 (delta 0)
To https://github.com/schacon/simplegit
 * [new branch]      serverfix -> serverfix

Git은 serverfix라는 브랜치 이름을 refs/heads/serverfix:refs/heads/ serverfix 로 확장한다.

이것은 <serverfix 라는 로컬 브랜치>를 서버로 Push 하는데 <리모트의 serverfix 브랜치>로 업데이트한다는 것을 의미한다. 

-> 나중에 누군가 저장소를 Fetch 하고 나서 서버에 있는 serverfix 브랜치에 접근할 때 origin/serverfix 라는 이름으로 접근할 수 있다.

 

* 이때, fetch 명령으로 리모트 트래킹 브랜치를 내려받는다고 해서 로컬 저장소에 수정할 수 있는 그 브랜치가 생기는 것은 아니다. serverfix브랜치가 생기는 게 아니라 수정 못하는 origin/ serverfix 브랜치 포인터가 생기는 것!

$ git merge origin/serverfix : 새로 받은 브랜치의 내용을 merge할 때

$ git checkout -b serverfix origin/serverfix : merge하지 않고 리모트 트래킹 브랜치에서 시작하는 새 브랜치를 만들 때

 

브랜치 추적

리모트 트래킹 브랜치를 로컬 브랜치로 checkout하면 자동으로 트래킹 브랜치가 생성된다. (Upstream)

트래킹 브랜치에서 $ git pull 하면 리모트 저장소로부터 데이터를 내려받아 연결된 리모트 브랜치와 자동으로 merge한다.

$ git checkout —track origin/serverfix / $ git checkout serverfix

$ git fetch —all; git branch -vv
위와 같이 서버에서 최신 데이터를 가져온 다음, 추적 상황을 확인하자

 

Pull

Clone 이나 checkout으로 추적 브랜치가 설정되면 git pull 쓸 수 있다.

pull은 fetch 와 merge를 동시에 수행하는데 일반적으로 fetch와 merge 명령을 따로 실행한다.

 

 


이 글은 아래 git 공식 페이지를 참고하면서 공부해본 내용을 정리한 것이다. 더 상세한 설명과 예시를 보고 싶으면 아래 참고 사이트를 참고하길 바란다!

 

 

<참고사이트>

 

Git - 리모트 브랜치

``origin'' 의 의미 브랜치 이름으로 많이 사용하는 master'' 라는 이름이 괜히 특별한 의미를 가지는 게 아닌 것처럼 origin'' 도 특별한 의미가 있는 것은 아니다. git init 명령이 자동으로 만들기 때문

git-scm.com