Git 프로토콜

개발공부/Git

Git 프로토콜

개발자 찐빵이 2024. 6. 8. 18:27

728x90

Git은 Local, HTTP, SSH, Git 이렇게 네 가지의 프로토콜을 사용한다.

로컬 프로토콜

Git Clone 시 파일 경로를 직접 쓸 때와 file:// 로 시작하는 URL을 사용할 때는 다르게 처리된다.

디렉토리 경로를 그대로 사용하는 경우

ex) git clone /srv/git/project.git

Git은 필요한 파일을 직접 복사하거나 하드 링크를 사용한다. 빠르지만 복사본이 생성되어 폴더가 지저분할 수 있음.

`file://` 로 시작하는 경우

Git은 네트워크를 통해서 데이터를 전송할 때처럼 프로세스를 별도로 생성하여 처리한다.

프로세스로 데이터를 전송하는 게 직접 복사하는 것보다 효율이 떨어지지만 외부 Refs나 개체들이 포함된 저장소의 복사본을 깨끗한 상태로 남겨둘 수 있는 장점이 있다.

로컬 프로토콜의 장점

기존의 네트워크나 파일의 권한을 그대로 사용하기 떄문에 간단하다.
동료가 작업하는 저장소에서 한 일을 바로 가져오기 좋다.

로컬 프로토콜의 단점

다양한 상황에서 디렉토리를 공유하는게 어렵다.
ex) 집에 있을 때 Push 해야하면 리모트 저장소가 있는 디스크에 마운트가 필요 → 다른 프로토콜을 이용하는 방법보다 느리고 어렵다.
파일시스템을 마운트해서 사용하는 중이라면 별로 빠르지도 않다.
우발적인 사고를 보호해주지 않는다. 모든 사용자가 리모트 디렉토리에서 무슨 짓이든지 할 수 있기 때문.

HTTP 프로토콜

HTTP 프로토콜을 사용하는 방식은 버전에 따라 차이가 난다. 1.6.6 이전 버전에서는 읽기만 가능한 단순한 방법이지만, 1.6.6 버전부터는 SSH나 Git 프로토콜처럼 통신하는 스마트한 방법으로 통신한다.

스마트한 HTTP (1.6.6 이후)

SSH나 Git 프로토콜처럼 통신하지만 HTTP 인증 방식을 사용한다.

HTTP 인증은 사용자 이름과 암호만으로 인증할 수 있어서 더 편리하게 사용할 수 있다.

멍청한 HTTP (1.6.6 미만)

Git 서버가 스마트한 HTTP 요청에 응답하지 않으면 차선책으로 멍청한 HTTP 프로토콜을 시도한다.

이 프로토콜은 원격 저장소를 그냥 파일을 건네주는 웹 서버로 취급한다.

이 프로토콜은 자주 사용 안하고 보통은 스마트 HTTP 프로토콜만 이용한다.

스마트 HTTP 프로토콜의 장점

읽고 쓰는데 하나의 URL만 사용한다.
사용자에게 익숙한 사용자 이름과 암호 방식의 인증을 사용하는데 이 방식이 SSH에 비해 간단하다.
보편적인 프로토콜이라 거의 모든 회사 방화벽에서 통과 가능하다.

스마트 HTTP 프로토콜의 단점

간혹 HTTPS를 사용하도록 설정하는 것이 SSH로 설정하는 것 보다 까다로운 서버가 있다.
Push할 때 HTTP 인증을 사용하면 SSH 인증키를 사용하는 것 보다 더 복잡하다. → 인증 캐싱 툴을 사용하면 좀 낫다.

SSH 프로토콜

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

SSH 프로토콜의 장점

SSH 데몬이 흔하기 때문에 상대적으로 설정하기 쉽다.
모든 데이터가 암호화 되어 인증된 상태로 전송되기 때문에 보안에 안전하다.
전송 시 데이터를 압축하기 때문에 효율적이다.

SSH 프로토콜의 단점

익명으로 접근할 수 없다. (읽기도 X)
익명 접근이 가능하게 하려면 Push 할 때는 SSH로 하고 Fetch 시 다른 프로토콜을 사용하도록 설정해야한다.