Git, 분산버전 관리시스템(8) - 원격 저장소를 이용하여 작업하기
1. 원격 저장소를 이용하여 작업하기
1.1. 네트워크 프로토콜
Git에서는 원격 저장소와 통신하는 데는 3종류의 프로토콜을 사용한다.
l SSH
l git
l HTTP/HTTPS
1.1.1. SSH
SSH(Secure Shell)로 저장소에 접근하는 방식은, 한 가지 차이점을 제외하고는 저장소의 파일 시스템에 직접 접근하는 방식과 유사하다.
원격 저장소에 대해서는 저장소 경로 앞에 도메인명을 추가하고, 필요하다면 사용자명도 추가한다.
git@github.com부분이 기본 파일 시스템 URL에 추가된 SSH URL의 유일한 차이점이다.
이 정보를 바탕으로 Git은, SSH를 사용하여 git이라는 사용자명으로 github.com 서버에 로그인하고 tswicegood/mysite-chp6.git 경로에 위치한 저장소를 복제한다.
사용자명 | github.com 서버 | 저장소 경로 |
git@ 에 해당하는 사용자명은 필수 사항이 아니다.
자신의 컴퓨터에서 사용하는 사용자명과 접속하려는 원격 서버의 사용자명이 동일한 경우 사용자명을 지정하지 않아도 된다.
서버에 로그인 하려고 하나의 사용자 계정을 팀원 간에 공유하고, 원격 서버에 대한 접근 권한은 각 사용자가 제공한 인증서를 통해서 확인하는 경우는 흔하다.
1.1.2. git
Git에는 속도를 위해 설계된 전용 프로토콜이 있다.
가장 빠른 프로토콜이긴 하지만 다른 네트워크에서 사용하지 않는 9418번 포트를 사용하므로 방화벽에 차단되는 문제가 발생할 수 있다.
아래는 git 프로토콜을 사용하는 저장소 URL 형태를 나타낸다.
git://은 프로토콜을 명시하며 뒤이어 서버를 의미하는 github.com과 저장소 명이 나온다.
git://github.com/tswicegood/mysite-chp6.git | ||
프로토콜 | github.com 서버 | 저장소 경로 |
위 예에서 저장소의 전체 경로를 지정하지는 않았다.
Git 서버를 시작할 때 저장소가 포함된 디렉터리를 지정해야 한다.
클라이언트는 접근하려는 저장소명만 지정하면 된다.
암호화 기능을 제외하고 익명 접근을 사용한다는 점이 git 프로토콜과 SSH의 가장 큰 차이점이다. 저장소를 읽기 전용으로 공개할 생각이라면 익명 접근을 허용하는 게 괜찮은 생각이지만, 쓰기 권한까지 허용한다면 위험할 수 있다.
URL이 ‘git://’으로 시작한다면 대부분은 읽기 전용이라고 생각하면 된다.
일반적으로 개발자들은 변경 사항을 가져오려고 풀링 할 때는 git 프로토콜을 활용하고, 공유하려고 푸싱할 때는 SSH를 사용한다.
1.1.3. HTTP/HTTPS
HTTP 프로토콜은 일반적으로 마지막 수단으로 고려된다.
변경사항을 풀링 하는데 가장 비효율적인 방법이고, 네트워크 부하도 크긴 하지만, 거의 대부분의 방화벽에서 허용되며 설정 또한 비교적 쉽고 빠르기 때문이다.
만약 GitHub가 저장소에 HTTP 접근을 허용하고 github.com 서버에 있는 mysite-chp6.git 를 계속해서 사용한다면 다음과 같은 URL로 GitHub에 접근할 수 있다.
1.1.4. 네트워크 고르기
git 프로토콜, SSH, HTTP/HTTPS 중에서 어떤 네트워크를 사용할지 결정하는 데는 다양한 고려사항이 있다. 한가지만 선택한다면 어렵지 않다.
l 속도가 가장 중요한 경우 git 프로토콜을 사용한다.
l 보안에 가장 큰 가치를 둔다면 SSH가 적합한 프로토콜이다.
l 방화벽을 재설정하기 싫다면 HTTP/HTTPS가 유용한 방법이다.
문제는 인증인데 git 프로토콜은 익명 접근을 사용하므로 누구라도 저장소를 고칠 수 있다.
SSH로 저장소에서 작업하려면 적합한 사용자 권한이 필요하고,
HTTP/HTTPS는 WebDAV (Web-based Distributed Authoring and Versioning, 원격 웹 서버에 있는 파일을 여러 사용자가 함께 수정하고 관리할 수 있도록 돕는 일련의 HTTP 확장) 서버가 필요하다.
반드시 하나의 프로토콜만 사용해야 한다는 법은 없다.
속도와 보안의 균형을 맞추려면 한 가지 이상의 프로토콜을 섞어서 사용할 수 있다.
개인 저장소에서 SSH와 git 프로토콜을 조합하여 사용할 수 있다.
서버에 쓰기를 할 때는 SSH키를 사용하여 사용자를 인증하며,
git 프로토콜을 이용하여 익명의 읽기 권한을 허용한다.
설정은 Gitosis라는 프로그램을 사용하면 간단하다.
1.2. 원격 저장소 복제하기
원격 저장소를 복제하면 저장소의 지역 복사본이 생성된다.
복제 명령을 통해 생성된 지역 복사본은, git init으로 직접 생성한 저장소처럼 동작한다.
복제한 시점까지의 저장소 이력을 얻을 수 있는 게 유일한 차이점이다.
작업하려는 저장소를 복제하려면, 항상 git clone 명령어를 사용한다.
복제하려는 저장소명만 매개변수로 지정하는 게 가장 단순한 형식이다.
$ git clone git://github.com/tswicegood/mysite-chp6.git … |
git clone 은 서버에서 저장된 저장소를 다운로드하고, mysite-chp6 디렉토리에 저장소의 지역 복사본을 설정한다.
1.3. 최신 상태 유지하기
복제한 시점까지의 저장소 이력을 가져올 수는 있지만,
복제한 이후에도 다른 개발자들은 여전히 변경 사항을 만들어내고 저장소를 갱신한다.
따라서 원격 저장소에서 갱신된 변경 사항을 가져와야 한다
git fetch 명령어를 사용하면 변경 사항을 가져올 수 있다.
변경 사항을 가져오면 지역 저장소의 원격 브랜치가 갱신된다.
git branch를 실행하면 지역 브랜치를 확인할 수 있으며, 여기에 –r 매개변수를 추가하면 원격 브랜치를 볼 수도 있다.
$ git branch –r origin/HEAD origin/master |
원격 브랜치도 일반 브랜치와 마찬가지로 체크아웃 할 수는 있지만, 변경하면 안 된다.
원격 브랜치를 변경하려면, 먼저 원격 브랜치로부터 지역 브랜치를 생성한 다음 변경할 수 있다.
git fetch를 실행하면, 지역 저장소의 원격 브랜치가 갱신된다.
이때, 지역 브랜치에 가져온 변경사항을 합치지는 않는다.
원격 서버에서 변경 사항을 가져와서 동시에 지역 브랜치에 합치려면 git pull을 사용한다.
git pull은 2개의 매개변수가 필요한데,
풀링해서 가져오려는 원격 저장소와
가져온 내용을 반영할 브랜치이며, 브랜치명에는 origin/ 접두어를 사용하지 않는다.
원격 브랜치 명의 origin/ 접두어는 지역 브랜치와 원격 브랜치를 구분하려고 사용한다.
origin은 복제할 때 지역 저장소에 할당된 기본 원격 저장소명이다.
이제 원격 저장소로부터 변경 사항을 가져오거나(fetch) 풀링(pull)할 수 있다.
1.4. 변경 사항 푸싱하기
변경 사항을 푸싱한다는 말은, 변경 사항을 다른 저장소에 보냄을 의미한다.
푸싱은 자신의 커밋을 다른 저장소에 보낼 때 필요한 단계다.
커밋을 하면 알아서 중앙 저장소에 전달되는 전통적인 버전 관리 시스템과는 다르게, 분산 버전 관리 시스템에서 추가된 단계다.
git push에 매개변수를 지정하지 않으면 실행되는 몇 가지 기본동작이 있다.
우선 origin 저장소에 푸싱한다고 생각하며, 또한 지역 저장소의 현재 브랜치를 원격의 같은 이름의 브랜치에 푸싱한다고 여긴다 (기본동작은 동일한 이름의 브랜치에 푸싱하도록 되어 있다. 브랜치를 다른 브랜치에 푸싱하도록 기본 구성을 변경할 수도 있지만, 흔한 경우가 아니므로 다루지 않는다). 이때, 원격 저장소에 같은 이름의 브랜치가 존재해야 한다.
$ git push |
git push 에 --dry-run 매개변수를 지정하면, 푸싱된 변경 사항을 확인할 수 있다.
git pull 에서처럼 푸싱하려는 저장소를 지정할 수도 있는데, git pull과 동일하게 git push <저장소> <참조> 형식을 사용한다.
<저장소>에는 모든 유효한 저장소를 지정할 수 있다. 7.1 ‘네트워크 프로토콜’의 URL이라면 잘 동작한다.
또한 7.5 ‘새로운 원격 저장소 추가하기’에서 다루는 저장소의 별칭을 이용해도 잘 동작한다.
<참조>의 가장 간단한 형태는 태그, 브랜치, HEAD와 같은 특수 키워드다.
<참조>를 사용하여 푸싱할 브랜치와 푸싱될 위치를 지정할 수 있다.
예를 들면, git push origin mybranch:master를 사용하여 mybranch의 변경 사항을 원격 master 브랜치에 푸싱할 수 있다.
1.4.1. 푸싱된 변경 사항 가져오기
흔하지는 않지만 다른 사람이 변경 사항을 자신의 개인 저장소에 푸싱하는 것을 허용해야 할 경우가 있으며, 자신이 푸싱해야 할 경우도 있다.
다양한 운영체제에서 코드를 테스트해야 할 경우, 다른 가상 머신에 있는 개인 저장소에 변경 사항을 푸싱한다.
자신의 저장소에 푸싱된 변경사항은 작업트리에 반영되지 않는다. 이를 통해 작업 트리에 있는 아직 커밋하지 않은 변경 사항을 누군가가 덮어쓰지 못하도록 한다.
저장소의 최신 변경 사항 전부를 작업 트리에 풀링하려면, git checkout HEAD를 실행한다. 이때 발생한 충돌은 5.4 ‘충돌 다루기’의 방법으로 처리할 수 있다.
1.5. 새로운 원격 저장소 추가하기
읽기나 쓰기 권한이 있다면 어떠한 저장소에도 푸싱하거나 풀링 할 수 있다.
동기화할 때마다 저장소명 전체를 매번 입력하는 것은 귀찮다.
특히 동일한 저장소와 계속해서 동기화한다면 정말 귀찮은 일이다.
기본 원격 저장소는 origin이라고 하며, 복제한 저장소의 전체 이름에 대한 별칭이다.
팀에 Erin이라는 개발자가 속해 있고, 그녀의 저장소로부터 빈번하게 변경사항을 풀링하고 있다고 하자.
Erin의 저장소에서 한 번만 풀링 한다면 git pull에 그녀의 저장소를 지정하여, 다음과 같이 실행할 수 있다.
$ git pull git://ourcompany.com/dev-erin.git |
한 번이라면 괜찮지만, 여러 번 풀링 한다면 키보드 입력을 줄일 수 있도록, 별칭을 추가하는 게 나은 선택이다.
원격 저장소에 새로운 별칭을 추가하려면, git remote add <이름> <저장소 URL>을 사용한다.
다음 명령은 Erin의 저장소에 별칭을 지정한다.
$ git remote add erin git://ourcompany.com/dev-erin.git |
이제 변경 사항을 푸싱하거나 풀링 할 때 전체 저장소명 대신에, 별칭인 erin을 사용하면 된다. 별칭을 이용해서 이전과 동일한 풀링을 다음과 같이 할 수 있다.
$ git pull erin HEAD |
별칭은 사용자가 원하는 어떠한 형태의 이름도 지정할 수 있어나, 반드시 고유한 이름을 지정해야 한다. erin이나 origin은 오직 한 개만 사용할 수 있다.
origin으로 지정된 저장소가 없다면, git remote add를 사용하여 저장소에 origin 별칭을 추가할 수 있다. origin은 git init으로 자신의 컴퓨터에서 저장소를 시작한 다음 원격 저장소로 보내야 할 때 유용하다.
git remote 명령어에는 몇 가지 유용한 기능이 더 있다.
우선 매개변수를 지정하지 않고 실행하면 추가한 모든 원격 저장소의 목록을 확인할 수 있다.
또한, git remote show <이름>을 실행하면 지정한 원격 저장소의 정보를 볼 수 있다.
별칭이 더 이상 필요하지 않거나, 다른 저장소의 별칭을 사용하고 싶다면 git remote rm을 실행하여 별칭을 제거할 수 있다.
1.5.1. 로컬 컴퓨터에서 생성된 프로젝트를 원격 저장소에 추가하기.
이미 이력이 있는 진행 중인 프로젝트라면 저장소를 복제하여 작업을 시작하는 게 좋지만, 자신의 컴퓨터에서 git init로 프로젝트를 생성했다면, 변경 사항을 어떻게 원격 저장소에 푸싱할 수 있을까?
7.5 ‘새로운 원격 저장소 추가하기’에서 알아본 git remote add 명령어로 푸싱하려는 저장소를 추가하면 된다..
변경 사항을 푸싱하려는 저장소가 기본 저장소라면, 원격 저장소를 origin으로 별칭을 지정한다.
예를 들어, 프로젝트를 git@example.com:/repos/pocus.git 이란 원격 저장소에 추가한다면 다음과 같이 실행할 수 있다.
$ git remote add origin git@example.com:/repos/pocus.git $ git push origin master …Git 출력 결과… |