Git 서버 I

Git 서버

---

프로토콜

---

Git는 Local, HTTP, SSH, Git 이렇게 네 가지의 프로토콜을 사용할 수 있다.

로컬 프로토콜

---

리모트 저장소가 단순히 디스크의 다른 디렉토리에 있을 때 사용한다.

공유 파일시스템을 마운트 했을 때는 로컬 저장소를 사용하는 것처럼 Clone 하고 Push 하고 Pull 하면 된다.

$ git clone /srv/git/project.git

실습)

아래처럼도 가능하다.

$ git clone file:///srv/git/project.git

실습)

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

디렉토리 경로를 그대로 사용하면 Git는 필요한 파일을 직접 복사하거나 하드 링크를 사용한다.

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

URL을 사용하면 외부 Refs나 개체들이 포함된 저장소의 복사본을 깨끗한 상태로 남겨둔다.

이미 생성한 Git 프로젝트에는 아래와 같이 로컬 저장소를 추가한다.

$ git remote add local_proj /srv/git/project.git/

그러면 네트워크에 있는 리모트 저장소처럼 Push 하거나 Pull 할 수 있다.

장점

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

다른 디렉토리를 공유할 때처럼 모든 동료가 읽고 쓸 수 있는 공유 디렉토리에 Bare 저장소를 만들면 된다.

단점

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

이 프로토콜은 저장소에 우발적인 사고가 발생하지 않도록 보호해주지 않는다.

HTTP 프로토콜

---

1.6.6 이전 버전에서는 읽기만 가능한 단순한 방법밖에 사용할 수 없었다. 

스마트 HTTP

SSH나 Git 프로토콜처럼 통신한다.

다만 HTTP나 HTTPS 포트를 이용해 통신하고 다양한 HTTP 인증 방식을 사용한다는 것이 다르다.

HTTP는 사용자 이름과 암호만으로 인증할 수 있기 때문에 더 편리하게 사용할 수 있다.

 git://  프로토콜처럼 익명으로 사용할 수 도 있고, SSH처럼 인증을 거쳐 Push 할 수도 있다.

이 두가지 동작을 다른 URL로 나눌 필요없이 하나의 URL로 통합해서 사용할 수 있다.

인증기를 켜놓은 저장소에 Push를 하면 서버는 사용자 이름과 암호를 물어본다. 

그리고 Fetch나 Pull 같은 읽기 작업에서도 같은 URL을 사용한다.

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 $ mk hooks/post-update.sample hook/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

단순히 Bare 저장소를 HTTP 문서 루트에 넣으면 된다.

장점

읽기와 쓰기에 하나의 URL만 사용한다.

사용자에게 익숙한 사용자이름과 암호 방식의 인증을 사용한다.

SSH에 비해 사용하기 간단하다.

SSH는 사용자가 알아서 키를 만들고 공개키를 서버에 올린 후에야 인증을 받을 수 있다.

HTTP대신 HTTPS를 이용해서 전송하는 데이터를 암호화하는 것과

클라이언트에게 서명된 SSL 인증 서를 요구하는 것도 가능하다.

HTTP는 보편적인 프로토콜이기 때문에 거의 모든 회사 방화벽에서 통과하도록 돼있다는 장점도 있다.

단점

HTTP나 HTTPS를 사용하도록 설정하는 것이 SSH로 설정하는 것보다 까다로운 서버가 있다.

Push 할 때 HTTP 인증을 사용하면 SSH 인증키를 사용하는 것보다 좀 더 복잡하다.

SSH 프로토콜

---

Git의 대표 프로토콜은 SSH이다.

SSH를 이용하면 아무런 외부 도구 없이 Git 서버를 구축할 수 있다.

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

SSH는 인증 기능이 있고 어디에서든 사용할 수 있으며 사용하기도 쉽다.

SSH를 통해 Git 저장소를 Clone 하려면  ssh://  로 시작하는 URL을 사용한다.

$ git clone ssh://user@server/project.git

아래와 같은 SCP 형태의 구문으로 줄여 쓸 수도 있다.

$ git clone user@server:project.git

사용자 계정을 생략할 수도 있는데 계정을 생햑하면 Git는 현재 로그인한 사용자의 계정을 사용한다.

장점

SSH는 상대적으로 설정하기 쉽다.

많은 네트워크 관리자들은 SSH 데몬을 다루어본 경험이 있고 대부분의 OS 배포판에는 SSH 데몬과 관리도구들이

모두 들어 있다.

SSH를 통해 접근하면 보안에 안전하다. 모든 데이터는 암호화되어 인증된 상태로 전송된다.

SSH는 전송 시 데이터를 가능한 압축하기 때문에 효율적이다.

단점

SSH는 익명으로 접근할 수 없다.

만약 SSH를 사용하는 프로젝트에 익명으로 접근할 수 있게 하려면, Push 할 때는 SSH로 하고 다른 사람들이

Fetch 할 때는 다른 프로토콜을 사용하도록 설정해야 한다.

Git 프로토콜

---

Git 프로토콜은 Git에 포함된 데몬을 사용하는 것이다.

포트는 9418이며 SSH 포로토콜과 비슷한 서비스를 제공하지만 인증 메커니즘이 없다.

저장소에 git-export-daemon-ok 파일을 만들면 Git 프로토콜로 서비스할 수 있지만, 보안은 없다.

이 파일이 없는 저장소는 서비스되지 않는다.

이 저장소는 누구나 Clone 할 수 있거나 아무도 Clone 할 수 없거나 둘 중의 하나만 선택할 수 있다.

장점

Git 프로토콜은 전송 속도가 가장 빠르다고 할 수 있다.

전송량이 많은 공개 프로젝트나 별도의 인증이 필요 없고 읽기만 허용하는 프로젝트를 서비스할 때 유용하다.

함호화 인증을 빼면 SSH 프로토콜과 전송 메커니즘이 별반 다르지 않다.

단점

Git 프로토콜의 단점은 인증 메커니즘이 없다는 것이다.

Git 프로토콜만으로 접근할 수 있는 프로젝트는 바람직하지 못하다. 

일반적으로 SSH 나 HTTPS 프로토콜과 함께 사용한다.

별고의 데몬이 필요하고 프로젝트에 맞게 설정해야 한다.

자원을 아낄 수 있도록 xinetd같은 것도 설정해야 하고 방화벽을 통과할 수 있도록 9418 포트토 열어야 한다.

이 포트는 일반적으로 허용하는 표준 포트가 아니다. 

서버에 Git 설치하기

---

Linux에 설치하는 방법에 대해서만 간단히 설명한다.

어떤 서버를 설치하더라도 일단 저장소를 Bare 저장소로 만들어야 한다.

Bare 저장소는 워킹 디렉토리가 없는 저장소이다.  --bare  옵션을 주고 Clone 하면 새로운 Bare 저장소가 만들어진다.

Bare 저장소 디렉토리는 관례에 따라 .git 확장자로 끝난다.

$ git clone --bare my_project my_project.git Cloning into bare repository 'my_project.git'... done.

이제 my_project.git 디렉토리에는 복사한 Git 디렉토리 데이터만 들어 있다.

아래와 같이 실행한 것과 비슷하다.

$ cp -Rf my_project/.git my_project.git

서버에 Bare 저장소 넣기

---

만들어진 Bare 저장소를 서버에 넣고 프로토콜을 설정한다. 

git.example.com 이름의 서버에 SSH로 접속할 수 있게 만들고 Git 저장소를  /srv/git  디렉토리에 저장 한다.

$ scp -r my_project.git user@git.example.com:/srv/git

이제 다른 사용자들은 SSH로 서버에 접근해서 저장소를 Clone 할 수 있다.

사용자는  /srv/git  디렉토리에 읽기 권한이 있어야 한다.

$ git clone user@git.example.com:/srv/git/my_project.git

이 서버에 SSH로 접근할 수 있는 사용자가  /svr/git/my_project.git  디렉토리에 쓰기 권한까지 가지고 있으면 Push 할 수 있다.

 git init  명령에  --shared  옵션을 추가하면 Git는 자동으로 그룹 쓰기 권한을 추가한다.

$ ssh user@git.example.com $ cd /srv/git/my_project.git $ git init --bare --shared

중앙집중식 워크플로

---

중앙집중식 워크플로

중앙 저장소를 하나 만들고 개발자 모두에게 Push 권한을 부여한다. 

모두에게 Push 권한을 부여해도 Git는 한 개발자가 다른 개발자의 작업 내용을 덮어쓰도록 허용하지 않는다.

John과 Jessica가 동시에 같은 부분을 수정하는 상황을 생각해보자. 

John이 먼저 작업을 끝내고 수정한 내용을 서버로 Push 한다.

Jessica도 마찬가지로 작업을 끝내고 수정한 내용을 Push하려 하지만 서버가 바로 받아주지 않는다. 

서버에는 John이 수정한 내용이 추가 되었기 때문에 Push 하기 전에 Fetch로 받아서 Merge 한 후 Push 할 수 있다.

Integration-Manager 워크플로

---

1. 프로젝트 Integration-Manager 는 프로젝트 메인 저장소에 Push를 한다.

2. 프로젝트 기여자는 메인 저장소를 Clone 하고 수정한다.

3. 기여자는 자신의 저장소에 Push 하고 integration-Manager 가 접근할 수 있도록 공개해 놓는다.

4. 기여자는 Integration-Manager에게 변경사항을 적용해 줄 것을 이메일로 요청한다.

5. Intergration-Manager는 기여자의 저장소를 리모트 저장소로 등록하고 수정사항을 Merge 하여 테스트한다.

6. Intergration-Manager는 Merge 한 사항을 메인 저장소에 Push 한다.

Integration-manager workflow

이 방식은 GitHub나 GitLab 같은 Hub 사이틀을 통해 주로 사용하는 방식이다.

프로젝트를 Fork 하고 수정사항을 반영하여 다시 모두에게 공개하기 좋은 구조로 되어 있다.

이 방식의 장점은 기여자와 Intergration-Manager가 각자의 사정에 맞춰 프로젝트를 유지할 수 있다는 점이다.

기여자는 자신의 저장소와 브랜치에서 수정 작업을 계속해 나갈 수 있고 수정사항이 프로젝트에 반영되도록

기다릴 필요가 없다. 관리자는 여유를 가지고 기여자가 Push 해 놓은 커밋을 적절한 시점에 Merge 한다.

Dictator and Lieutenants 워크플로

---

이 방식은 저장소를 여러개 운영하는 방식을 변형한 구조이다.

보통 수백 명의 개발자가 참여하는 아주 큰 프로젝트를 운영할 때 이 방식을 사용한다.

Linux 커넣 프로젝트가 대표적이다.

여러 명의 Intergration-Manager가 저장소에서 자신이 맡은 부분만을 담당하는데 이들을 Lieutenants라고 부른다.

모든 Lieutenant는 최종 관리자 아래에 있으며 이 최종 관리자를 Benevolent Dictator라고 부른다.

Benevolent Dicatator는 Lieutenant의 저장소를 가져와 공식 저장소에 Push 하고 모든 프로젝트 참여자는

이공식 저장소에서 반드시 Pull해야 한다.

1. 개발자는 코드를 수정하고 master 브랜치를 기준으로 자신의 토픽 브랜치를 Rebase 한다.

여기서 master 브랜치란 공식 저장소의 브랜치를 말한다.

2. Lieutenant들은 개발자들의 수정사항을 자신이 관리하는 master 브랜치에 Merge 한다.

3. Dictator는 Lieutenant의 master 브랜치를 자신의 master 브랜치로 Merge 한다.

4. Dictator는 자신의 master 브랜치를 Push 하며 다른 모든 개발자는 

Dictator의 master 브랜치를 기준으로 Rebase 한다.

Benevolent dictator workflow

이 방식이 일반적이지 않지만 깊은 계층 구조를 가지는 환경이나 규모가 큰 프로젝트에서는 매우 유용하다.

프로젝트 리더가 모든 코드를 통합하기 전에 코드를 부분부분 통합하도록 여러 명의 Lieutenant에게 위임한다.