머가필요해

이번에는 가장 많이 사용하는 프로토콜인 SSH !!!


1. clone

$ git clone ssh://chani@10.0.2.15:/srv/repository/BareRepo.git $ git clone chani@10.0.2.15:/srv/repository/BareRepo.git

ssh 프로토콜을 사용하여 clone을 하는 방법은 2가지가 있다.

   - git clone ssh://계정@서버주소:리포지토리주소
   - git clone 계정@서버주소:리포지토리주소

하지만, 위의 스크린샷을 보면 에러가 발생한다!!!
그 이유는 ssh server가 없어서이다 ^^



2. install ssh server

$ sudo apt-get install openssh-server

Ubuntu의 경우에 가장 많이 사용하는 'openssh-server'를 설치하자.



3. clone

$ git clone chani@10.0.2.15:/srv/repository/BareRepo.git

실제로 해보면 "ssh://"를 명시하는 방법은 에러가 나곤 한다.
그냥 밑의 방법을 사용하는 것을 추천한다.






SSH를 사용하여 Git의 계정 관리를 하는 것이 가장 일반적이다.
앞에서 언급한 바와 같이 가장 대중적이며 안정적이며 유연한 프로토콜이다.

단점은 SSH를 사용할 경우, anonymous 접근을 허용하기가 난해하다.
그래서 open source project 에는 적용하지 않는다.

 

실제 계정 정책을 적용할 때 어떻게 해야하는지 등에 대한 부분은 다음에 별도로 다루겠다~

퇴근하고, 아가랑 놀고, 씻고....그리고 정리하려면 너무 졸려서리...... ㅠㅠ

작업을 위한 repository가 아닌 서버의 역할을 하기 위한 repository에 대해서 한동안 알아보도록 하겠다.

우선 가장 첫번째로 그냥 바로 사용할 수 있는 Local Protocol 이다!


1. git init --bare

 

$ mkdir  BareRepo.git $ cd BareRepo.git/ $ git init --bare

Bare repository를 생성하는 것에 대해서 작성한 다음 글을 참조하기 바란다.
   - http://whatwant.tistory.com/328

전에 이야기한 적이 있는 것 같은데, 다시 한 번 말하면
Bare repository는 일반적으로 디렉토리명 꼬리에 '.git'을 붙이곤 한다.


그리고 생성 후에 원활한 테스트를 위해서는 파일 하나는 넣어놓는 것이 좋다.
빈 저장소(empty repository)인 경우에는 테스트할 때 이상 증세를 보일 수도 있다.

예를 들어서 Redmine에서 저장소 셋팅을 제대로 하여도 empty repository인 경우에는
마치 에러가 난 것과 같은 화면을 보여준다.



2. clone

$ cd clone /srv/repository/BareRepo.git $ cd BareRepo/

Local Protocol을 사용하는 경우에는 repository 주소를 그냥 절대경로로 디렉토리를 적어주면 된다.

   - git clone [directory]

물론 해당 디렉토리에 대한 읽기 권한이 있어야 한다.

repository의 디렉토리명에 ".git"이 붙어 있음에도 생성된 repository를 보면
이름에서 ".git"이 제외되고 생성된 것을 볼 수 있을 것이다.


3. Usage

전에 간단히 언급은 했지만,
Local Protocol은 NFS로 공유 파일 시스템을 셋팅하여서 팀원들끼리 같이 사용하는 형태로 종종 사용은 된다.

권한 문제는 파일시스템의 계정 권한을 그대로 따른다.
물론 push 역시 계정 권한에 따라 허용된다.

혼자서 git을 구성해서 사용할 경우에는 간단히 Local Protocol을 사용하면 된다.

하지만, 일반적으로 사용할 경우 별 문제는 없지만,
만약 원격지에서 접근을 해야하는 경우에는 치명적으로 난감한 상황에 빠지게 된다.

작업을 위한 Repository가 아닌 소스 배포(?)를 위한 진정한 Server Repository에 대해서 알아보고자 한다.

자고로 Server라 함은 어떤 방식으로 파일을 주고 받을지를 정해야 한다.
바로 Protocol 이다!


Git 에서 사용할 수 있는 Protocol 은 총 4가지 방식이다.

   - Local
   - SSH
   - Git
   - HTTP/S
 


1. Local

아무것도 하지 않아도 사용할 수 있는 가장 기본적인 Protocol이다.
NFS 와 같은 것을 사용하여 공유 디렉토리 같은 것을 사용하여 그냥 막 접근하여 사용하는 방식이다.

개인 사용자가 혼자서 사용할 경우에나 추천하는 방식이며,
팀 작업을 할 경우나 일반 인터넷망에서 사용하는 경우에는 절대 추천하지 않는 방식이다.

폐쇄된 내부에서 같은 망에 물려있는 팀 내에서만 사용하는 경우에나 적용할 수 있을 것이다.



2. SSH

리눅스 환경에서 대부분 사용하는 터미널 접근 방식이다.
telnet과 달리 어느정도 보장된 보안 프로토콜이며, 가장 대중적인 프로토콜이다.

Git을 리눅스 환경에서 사용하고 있다면, 가장 추천하는 방식이다.
물론 윈도우 환경에서도 적용은 할 수 있다.

단, SSH 프로토콜을 사용할 경우 anonymous 접속을 허용하기가 조금 난감해진다.



3. Git

기본적으로 포함되어 있는 Git 데몬을 띄우면 사용할 수 있는 'Git의 Git에 의한 Git을 위한 프로토콜'이다.
일반적으로는 9418 포트를 사용하며, SSH 프로토콜과는 유사한 방식이지만, 인증은 빠진 형태이다.
 
Git 프로토콜의 가장 큰 장점은 '속도'이다. 가장 빠르다!!!
만약 인증이 필요없지만 용량이 큰 프로젝트를 제공하는 상황이라면 무조건 Git 프로토콜을 사용해라!
SSH와 같은 방식이지만, 암호화와 인증이 없기에 자료 전송에 있어서는 짱이다.

다만, 인증 과정이 없기에 읽기 전용으로나 사용해야한다.
그래서 실제로는 push는 SSH 프로토콜을 사용하고, clone 등의 작업은 Git 프로토콜을 사용하곤 한다.



4. HTTP/S

최근 들어서 형상관리 도구를 포함한 많은 분야에서 상당히 일반화되고 있는 HTTP/S 프로토콜이다.

HTTP 문서의 root 디렉토리 밑으로 repository를 넣어놓고,
Git의 hooks 설정만 살짝 해놓으면 되는 간편한 사용법의 프로토콜이다.

HTTP/S의 가장 큰 장점은 대중적인 HTTP/S 포트를 사용하기에, 방화벽 등의 문제에 걸릴 위험이 없다!
또한 HTTPS의 경우에는 SSH 프로토콜과 같이 맞물려서 재미있게(?) 사용할 수도 있다.

다만, 가장 큰 단점은 속도가 느리다는 점이다.
또한 그닥 다이나믹한 기능을 제공하는 프로토콜도 아니다.
그다지 똑똑한 프로토콜이 아니기에 완벽한 전송을 보장한다고 보기에도 어렵다.(하지만 대부분 잘 되긴한다!)






각 프로토콜을 어떻게 설정을 해서 어떻게 사용을 하는지 하나 하나 살펴보고 싶기는한데,
일단 오늘은 지금 졸리기에 여기서 마무리 짓고~

나중에 기분이 어떤지에 따라서.... ^^


개인적으로는 SSH 프로토콜을 사용하는 gitolite를 적용하는 것을 추천하기에
그에 대해서 알아볼 것 같다. ^^