감 1도 없는 개발자

감 1도 없는 개발자

여행을 꿈꾸는 개발자

Pro git - 4.1

Updated:

Pro git - 프로토콜

0. 프로토콜

  • 리모트 저장소는 일반적으로 워킹 디렉토리가 없는 Bare 저장소 이다.
  • 이 저장소는 협업용이기 때문에 체크아웃이 필요 없다. 그냥 Git 데이터만 있으면 된다.
  • 다시 말해서 Bare 저장소는 일반 프로젝트에서 .git 디렉토리만 있는 저장소다.
  • Git은 Local, HTTP, SSH, Git 이렇게 네 가지의 프로토콜을 사용할 수 있다.

1. 로컬 프로토콜

  • 리모트 저장소가 단순히 같은 시스템의 다른 디렉토리에 있을 때 사용한다.
  • 팀원들이 전부 한 시스템에 로그인하여 개발하거나 NFS같은 파일시스템을 공유하고 있을 때 사용한다.
  • 모든 저장소가 한 시스템에 있기 때문에 한순간에 모두 잃을 수 있다.
  • 공유 파일시스템을 마운트했을 때는 로컬 저장소를 사용하는 것처럼 Clone 하고 Push 하고 Pull 하면 된다.
  • 일단 저장소를 Clone 하거나 프로젝트에 리모트 저장소로 추가한다.
  • 추가할 때 URL 자리에 저장소의 경로를 사용한다.
  • 아래는 예시
$ git clone /srv/git/project.git
$ git clone file:///srv/git/project.git
  • Git은 파일 경로를 직접 쓸 때와 file:// 로 시작하는 URL을 사용할 때를 약간 다르게 처리한다.
  • 디렉토리 경로를 그대로 사용하면 Git은 필요한 파일을 직접 복사하거나 하드 링크를 사용한다.
  • 하지만 file:// 로 시작하면 Git은 네트워크를 통해서 데이터를 전송할 때처럼 프로세스를 별도로 생성하여 처리한다.
  • 단점은 이 프로세스로 데이터를 전송하는 것은 효율이 좀 떨어진다.
  • 장점은 외부 Refs나 개체들이 포함된 저장소의 복사본을 깨끗한 상태로 남겨둘 때 사용한다.
  • 보통은 다른 버전 관리 시스템들에서 임포트한 후에 사용한다.

  • 일단은 빠른 디렉토리 경로를 사용한다.

  • 이미 가진 Git 프로젝트에는 아래와 같이 로컬 저장소를 추가한다.
git remote add local_proj /srv/git/project.git
  • 그러면 네트워크에 있는 리모트 저장소처럼 local_proj 이름으로 리모트처럼 Push 하거나 Pull 할 수 있다.

1.1 장점

  1. 파일 기반 저장소의 장점은 간단하다는 것이다.

    • 기존에 있던 네트워크나 파일의 권한을 그대로 사용하기 때문에 설정하기 쉽다

  2. 동료가 작업하는 저장소에서 한 일을 바로 가져오기에도 좋다.

    • 만약 동료의 한 일을 확인하고자 한다면 동료가 push하고 내가 pull할 필요가 없다.

    • 예를 들어 git pull /home/john/project 처럼 명령어를 실행시켜서 동료의 코드를 가져올 수 있다.

1.2 단점

  1. 다양한 상황에서 접근할 수 있도록 디렉토리를 공유하는 것 자체가 일반적으로 어렵다.

    • 집에 있을 때 Push 해야 하면 리모트 저장소가 있는 디스크를 마운트해야 하는데 이것은 다른 프로토콜을 이용하는 방법보다 느리고 어렵다.

  2. 파일시스템을 마운트해서 사용하는 중이라면 별로 빠르지도 않다.

    • 로컬 저장소는 데이터를 빠르게 읽을 수 있을 때만 빠르다.

    • NFS에 있는 저장소에 Git을 사용하는 것은 보통 같은 서버에 SSH로 접근하는 것보다 느리다.

  3. 저장소에 우발적인 사고가 발생하지 않도록 보호해주지 않는다.

    • 모든 사용자는 쉘에서 “리모트” 디렉토리에 무슨 짓이든지 할 수 있다.

    • 누군가 저장소에 침범해서 Git 내부 파일을 삭제하고 변경하지 못하도록 하는 장치가 없다.

2. HTTP 프로토콜

  • Git은 HTTP로 통신할 때, 서로 다른 두 방법으로 HTTP를 사용할 수 있다.
  • 1.6.6 이전 버전에서는 읽기만 가능한 단순한 방법밖에 사용할 수 없었다.
  • 1.6.6 버전부터는 Git 데이터를 전송할 때 SSH처럼 서로 협상한다.
  • 이 프로토콜을 보통 스마트 HTTP 프로토콜이라 한다.

2.1 스마트 HTTP

  • 스마트 HTTP 프로토콜은 SSH나 Git 프로토콜처럼 통신한다.
  • 다만 HTTP나 HTTPS 포트를 이용해 통신하고 다양한 HTTP 인증 방식을 사용한다는 것이 다르다
  • SSH는 키를 발급하고 관리해야 하는 번거로움이 있지만, HTTP는 사용자이름과 암호만으로 인증할 수 있기 때문에 더 편리하게 사용할 수 있다.
  • Git에서 가장 많이 사용하는 프로토콜이다.
  • git:// 프로토콜처럼 익명으로 사용할 수도 있고, SSH처럼 인증을 거쳐 Push 할 수도 있기 때문이다.
  • 이 두 가지 동작을 다른 URL로 나눌 필요없이 하나의 URL로 통합해서 사용할 수 있다.
  • 그냥 인증기능을 켜놓은 저장소에 Push를 하면 서버는 사용자이름과 암호를 물어본다.
  • 그리고 Fetch나 Pull 같은 읽기 작업에서도 같은 URL을 사용한다.

  • 실제로 GitHub 같은 서비스에서 제공하는 저장소는 Clone을 할 때나 Push를 할 때 같은 URL을 사용한다.

  • 예) https://github.com/sunlike0508/sunlike0508.git
2.1.1 장점
  • 읽기와 쓰기에 하나의 URL만 사용한다.
  • 사용자에게 익숙한 사용자이름과 암호 방식의 인증을 사용한다.
  • 사용자이름과 암호 방식의 인증이 SSH에 비해 사용하기 간단하다.
  • 게다가 SSH만큼이나 빠르고 효율적이기 까지 하다.
  • HTTPS를 이용해서 전송하는 데이터를 암호화하는 것도, 클라이언트에게 서명된 SSL 인증서를 요구하는 것도 가능하다.
  • HTTPS는 매우 보편적인 프로토콜이기 때문에 거의 모든 회사 방화벽에서 통과하도록 돼있다는 장점도 있다.
2.1.2 단점
  • HTTPS를 사용하도록 설정하는 것이 SSH로 설정하는 것보다 까다로운 서버가 있다.
  • 그것 말고는 스마트 HTTP 프로토콜이 다른 프로토콜보다 못한 단점은 별로 없다.
  • Push 할 때 HTTP 인증을 사용하면 SSH 인증키를 사용하는 것보다 좀 더 복잡하다. 그래도 인증 캐싱 툴을 사용하면 좀 낫다.

2.2 멍청한 HTTP

  • Git 서버가 스마트 HTTP 요청에 응답하지 않으면 Git 클라이언트는 차선책으로 멍청한 HTTP 프로토콜을 시도한다.
  • 원격 저장소를 그냥 파일 건네주는 웹 서버로 취급한다.
  • HTTP 도큐먼트 루트 밑에 Bare 저장소를 두고 post-update 훅을 설정하는 것이 기본적으로 해야 하는 일의 전부다.
  • 저장소가 있는 웹 서버에 접근할 수 있다면 그 저장소를 Clone 할 수도 있다.
  • 아래와 같이 HTTP를 통해서 저장소를 읽을 수 있게 한다.
$ cd /var/www/htdocs/
$ git clone --bare /path/to/git_project gitproject.git
$ cd gitproject.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update
  • post-update 훅은 Git에 포함되어 있으며 git update-server-info 라는 명령어를 실행시킨다.
  • 이 명령어를 써야 HTTP로 Fetch와 Clone 명령이 제대로 동작한다.
  • 누군가 SSH를 통해서 저장소에 Push 하면 post-update 훅이 실행된다.
  • 그럼 다른 사용자들은 Push 된 파일을 아래와 같이 Clone 할 수 있다.
$ git clone https://example.com/gitproject.git

  • 여기서는 Apache 서버를 사용해서 기본 루트 디렉토리인 /var/www/htdocs 를 사용하지만 다른 웹 서버를 사용해도 된다.

  • 단순히 Bare 저장소를 HTTP 문서 루트에 넣으면 된다.
  • Git 데이터는 일반적인 정적 파일처럼 취급된다.

3. SSH 프로토콜

  • Git의 대표 프로토콜은 SSH이다.
  • SSH를 이용하면 아무런 외부 도구 없이 Git 서버를 구축할 수 있다.

  • 대부분 서버는 SSH로 접근할 수 있도록 설정돼 있다.

  • 인증 기능이 있고 어디에서든 사용할 수 있으며 사용하기도 쉽다.
  • SSH를 통해 Git 저장소를 Clone 하려면 ssh:// 로 시작하는 URL을 사용한다:
$ git clone ssh://[user@]server/project.git
$ git clone [user@]server:project.git
  • 사용자 계정을 생략할 수도 있는데 계정을 생략하면 Git은 현재 로그인한 사용자의 계정을 사용한다.

3.1 장점

  1. SSH는 상대적으로 설정하기 쉽다.
  2. SSH를 통해 접근하면 보안에 안전하다.
  3. HTTPS, Local 프로토콜과 마찬가지로 전송 시 데이터를 가능한 압축하기 때문에 효율적이다.

3.2 단점

  • SSH는 익명으로 접근할 수 없다. 심지어 읽기 전용인 경우에도 익명으로 시스템에 접근할 수 없다.

  • 회사에서만 사용할 거라면 SSH가 가장 적합한 프로토콜일 것이지만 오픈소스 프로젝트는 SSH만으로는 부족하다.

  • 만약 SSH를 사용하는 프로젝트에 익명으로 접근할 수 있게 하려면, Push 할 때는 SSH로 하고 다른 사람들이 Fetch 할 때는 다른 프로토콜을 사용하도록 설정해야 한다.

4. Git 프로토콜

  • Git 프로토콜은 Git에 포함된 데몬을 사용하는 것이다.
  • 포트는 9418이며 SSH 프로토콜과 비슷한 서비스를 제공하지만, 인증 메커니즘이 없다.
  • 저장소에 git-export-daemon-ok 파일을 만들면 Git 프로토콜로 서비스할 수 있지만, 보안은 없다.
  • 이 파일이 없는 저장소는 서비스되지 않는다.
  • 이 저장소는 누구나 Clone 할 수 있거나 아무도 Clone 할 수 없거나 둘 중의 하나만 선택할 수 있다.

  • 그래서 이 프로토콜로는 Push 하게 할 수 없다. 엄밀히 말하자면 Push 할 수 있도록 설정할 수 있지만, 인증하도록 할 수 없다.

  • 즉, 당신이 Push 할 수 있으면 이 프로젝트의 URL을 아는 사람은 누구나 Push 할 수 있다.
  • 결론은 잘 안쓴다.

4.1 장점

  • Git 프로토콜은 전송 속도가 가장 빠르다고 할 수 있다.
  • 전송량이 많은 공개 프로젝트나 별도의 인증이 필요 없고 읽기만 허용하는 프로젝트를 서비스할 때 유용하다.
  • 암호화와 인증을 빼면 SSH 프로토콜과 전송 메커니즘이 별반 다르지 않다.

4.2 단점

  • Git 프로토콜의 단점은 인증 메커니즘이 없다는 것이다.
  • 따라서 인증 절차를 걸치기 위해 SSH나 HTTP를 사용하는데 여파로 설치가 어려운 프로토콜이다.
  • 별도의 데몬이 필요하고 프로젝트에 맞게 설정해야 한다.
  • 자원을 아낄 수 있도록 xinetd 같은 것도 설정해야 하고 방화벽을 통과할 수 있도록 9418 포트도 열어야 한다.
  • 이 포트는 일반적으로 회사들이 허용하는 표준 포트가 아니다.
  • 규모가 큰 회사의 방화벽이라면 당연히 이 포트를 막아 놓는다.

You may also enjoy