앞에서 Git Server 를 두고 그곳에서 소스를 받아오고 작업한 내용을 넣는 것을 살짝 살펴보았다.


Git을 소개할 때 항상 나오는 "분산 관리", 그에 따라 나오는 이야기는 바로 "복제"이다.
무슨 말인고 하니, 서버와 클라이언트 모두 똑같은 데이터를 가진다는 점을 특징으로 한다고 한다!

기존의 서버-클라이언트 구조인 Subversion 등과는 달리,
Git은 서버와 클라이언트 개념이 없이 모두 같은 데이터를 가지고 동등한 입장이라고들 말한다.

하지만, 이 이야기로 인하여 Git에 대한 많은 오해가 있고, 또 괜히 어려워 하게 되는 것 같다.


분산 관리 도구인 Git이지만,
형상관리 도구의 특성상 분명히 기본적인 구조는 "서버-클라이언트"이다.

즉, 최종적인 결과물을 저장하는 서버의 역할을 하는 repository는 분명히 존재한다.
그 외 clone을 받아간 repository는 모두 클라이언트 이다.

clone을 -bare 형식으로 하여 Server 역할을 할 수 있는 repository를 만들었더라도
전체 구조에서는 어디까지나 클라이언트의 역할이다.

말 장난같이 들릴지 모르겠지만, 위의 사항에 대해서는 잘 이해를 하였으면 좋겠다.



전체적인 흐름은 위와 같다.

   - Remote repository에서 'git clone'을 통해 소스를 받아오고
   - 소스 수정 작업을 한 뒤에
   - 'git add'를 통해 staged 상태로 만든 뒤
   - 'git commit'을 하고나서
   - 변경 사항을 'git push'를 통해 Remote repository로 넣어준다.


이 부분에 대해서 뭔가 말할 거리가 많다고 생각했는데,
막상 적다보니 짧은거 같아서 뭔가 조금 찜찜(?)한데.... 뭐 할 말은 다 한 것 같다!
빼먹은 부분이 있으면 나중에 다시 더 추가하도록 하고...
최신 트랜드에 따르기 위해서 요즘 유행한다는 인후염을 겪고 있다보니 헥헥....

반응형

'SCM > Git-GitHub' 카테고리의 다른 글

Remote - remote, fetch, pull  (0) 2012.03.19
업데이트 - git pull, 중간 정리  (0) 2012.03.17
Git Server - push + 한글  (1) 2012.02.26
Git Server - Remote Connect  (0) 2012.02.25
Git Server - SSH  (2) 2012.02.23

바로 앞에서 Remote repository 를 clone 하여서 받아왔다.
이번에는 만든 work repository 에서 작업한 내용을 Server로 보내는 작업을 해보자.

더불어서 git 에서 한글파일명을 쓸 때 발생하는 문제까지 같이 살펴보겠다.



1. modify + error


$ nano ./한글파일명.txt
$ git add ./한글파일명.txt
$ git commit -m 'push + 한글파일명 검증'

위 스크린샷에 모든 것이 나와있다.

새로운 계정에서 repository를 clone 하였고,
해당 work repository에서 새로운 파일을 추가한 다음에
commit을 하고자 하는데 여기서 바로 error가 발생을 했다!

error가 발생한 이유는,
"commit 을 하려고 하는데 누가 commit을 하려는 건지 정체를 알 수가 없으니 알려줘!!!"



2. user


$ git config --global.email bigbang@whatwant.com
$ git config --global.name bigbang
$ git commit -m 'push + 한글파일명 검증'

앞에서 살펴본바와 같이 git을 사용하기 전에는 항상 환경 설정을 해줘야 한다.

   - http://whatwant.tistory.com/295

그런데,
위 스크린샷을 보면 특이한 점을 볼 수 있을 것이다. 무엇인지 찾으실 수 있으신가요?!



3. push


$ git push

다음에 다시 한 번 제대로 설명을 하겠지만,

일단, 위에서 진행한 'commit'은 Server와 별개로 현재 계정의 work repository에서 작업을 한 것이다.
작업한 내용을 Server로 보내는 작업이 필요한데, 그것이 바로 " git push"이다.

그런데, 위 스크린샷을 보면 알겠지만 그냥 넘어가지 않고, error가 발생을 한다!

우리에게 모든 것을 알려주시는 친절한 git 선생님의 말씀을 잘 읽어보면,
권한(permission)이 충분하지 않다고 나온다.
그렇다! 바로 권한!!!



4. permission


서버 즉, Remote repository 의 권한을 한 번 살펴보자.

위 스크린샷을 보면 user와 group에게는 모두 권한을 주고 있지만,
다른 사용자들에게는 읽기 권한만 주고 있는 것을 확인할 수 있다.

그렇다!
이전에 계속 말한바와 같이 git은 어디까지나 기본적인 파일 권한을 기반으로 사용한다.

그러면, 여러 계정이 이 repository를 사용하게 하려면 어떻게 해야할까?



5. group


$ sudo groupadd barerepo
$ sudo usermod -G bigbang,barerepo bigbang

해당 repository를 사용하는 사용자들을 묶을 그룹을 하나 만들어보자.
   - sudo groupadd barerepo

사용자 'bigbang'을 barerepo 그룹에도 포함을 시키자.
   - sudo usermod -G bigbang.barerepo bigbang


일반적으로 'usermod'는 익숙하지 않을 것 같은데...
사용자의 정보를 변경하는 명령어이다. 그 중 '-G' 옵션은 그룹에 대한 정보를 변경한다는 의미이다.
여러 그룹에 속할 경우 ','로 나열을 하면 되고, 변경하고자 하는 계정은 제일 뒤에 적어주면 된다.

즉, 위 스크린샷에서는
" 'bigbang'이라는 계정은 'bigbang'이라는 그룹과 'barerepo'라는 그룹, 두 곳에 속한다! "
라는 의미이다.



6. chown


$ sudo chown -R chani.barerepo ./BareRepo.git 

위 스크린샷을 차례대로 살펴보길 바란다.

   - 'BareRepo.git' 은 chani 계정이 생성하였다. (주인은 chani)
   - 'chown'을 통해서 소유 group을 'barerepo'로 변경하였다.


'chown' 이라는 명령어에 대해서 조금 더 설명을 하자면,
당연하게도 소유자를 변경(chage owner)하기 위해서 사용을 하는 것이고,
하위 디렉토리 및 파일들도 일괄적으로 변경하기 위해서는 '-R' 옵션을 사용하면 된다.
user와 group은 '.'으로 연결하면 된다.


이제, 'BareRepo.git' repository는 barerepo 그룹 사용자들에게도 쓰기 권한이 있다!!!



7. push


$ git push 

이 부분을 테스트하면서 조금 의아심이 들었지만...
일단, 위에서 따라온 것처럼 권한 부분을 맞춰주면 스크린샷과 같이 정상적으로 push가 된다.

Remote repository로 변경 내역을 전달한 것이다!!!


여기서 의아하다는 점은,
분명 에러가 발생을 해야하는데 그냥 push가 되어버렸다는 점이다!!!


$ git config push.default tracking

본래는 push 를 어떻게 할 것인지 명시하지 않았기 때문에 error가 발생을 해야한다.
그런데, 왜 위 스크린샷에서 보는 것처럼 그냥 넘어갔는지는 의문이다.

만약, 여러분의 경우에 push할 때에 에러가 발생한다면,
혹 발생하지 않았더라도 위와 같이 tracking을 설정해놓으시길...



8. 한글파일명


한글 파일을 추가할 때 뭔가 이상하게 숫자들의 집합으로 등록이 된 것을 앞에서 확인했을 것이다.

 bigbang@chani-Ubuntu:~/workspace/BareRepo$ git commit -m 'push + 한글파일명 검증'
[master 5705788] push + 한글파일명 검증
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 "\355\225\234\352\270\200\355\214\214\354\235\274\353\252\205.txt"

잘못 등록된 것이 아니라 Unicode로 변경되어 전달된 것이다.
위 스크린샷을 보면 알겠지만, clone 을 하여도 제대로 파일명이 되어있는 것을 알 수 있을 것이다.

하지만, 위와 같이 등록이 될 경우에 일부 문제가 있을 수도 있다.
예를 들어서 Redmine의 저장소로 사용될 경우
파일의 이름이 한글이 아니라 저 숫자로 된 코드가 그대로 파일명으로 나오기도 한다.


$ sudo git config --system core.quotepath false

사용자 계정이 아니라 root 계정을 통해 system의 설정을 변경해야 한다.
이렇게 할 경우 다른 side effect가 있는지는 아직 모르겠다.


commit 부분을 살펴보면, 앞에서와 달리 한글이 그대로 반영되는 것을 볼 수 있을 것이다.


일단은 그냥 기본 값으로 사용하는 것을 추천하고,
Redmine의 경우와 같이 사용에 문제가 있을 경우 위와 같이 설정 변경을 통해 해결하는 것을 제안한다.

이로 인한 side effect에 대해서는 계속 확인을 해보겠다.



간만에 길게 쓴 포스팅인데, 춥고 졸리다! ㅠㅠ

반응형

'SCM > Git-GitHub' 카테고리의 다른 글

업데이트 - git pull, 중간 정리  (0) 2012.03.17
Remote Repository - git push  (2) 2012.03.04
Git Server - Remote Connect  (0) 2012.02.25
Git Server - SSH  (2) 2012.02.23
Git Server - Local  (0) 2012.02.22

Git 이 여러가지 Protocol 을 지원하고 있다지만, 어디까지나 기본 바탕은 SSH Protocol 이다!
계정 관리 및 계정의 권한 역시 SSH Protocol 의 정책이 그 기본이다.

앞에서 해당 Protocol 에 대해서는 간단히 알아보았고,
여기에서는 실제로 사용하는 모습을 간단히 시나리오에 따라서 살펴보도록 하겠다.



1. adduser


$ sudo adduser bigbang

우선 새로운 사용자를 하나 생성해보도록 하자.
위 스크린샷에서는 'bigbang'이라는 계정을 생성하였다.


$ sudo apt-get install finger
$ finger bigbang

꼭 설치해야하는 것은 아니지만, 그냥 계정을 확인할 수 있는 'finger'도 설치해보았다.
그냥... ^^



2. su


$ sudo su bigbang

일단 사용자를 변경하자.


프로젝트에 신입사원이 새로 왔다는 상황을 가정해보도록하겠다.
계정을 새로 발급을 받고 프로젝트 소스를 받아서 작업을 하고자 하는 상태다!



3. workspace


$ cd
$ mkdir workspace
$ cd ./workspace

repository를 내려받기 위한 공간을 마련하는 작업이다.
계정 홈디렉토리 밑에  workspace 라는 공간을 만들어서 그 밑에서 작업을 하고자 한다.



4. clone


$ git clone bigbang@localhost:/srv/repository/BareRepo.git

앞에서 살펴보았던 방법으로 ssh protocol 을 사용하여 repository 를 clone 하여보았다.



바로 곧 이어서 push에 대해서 살펴보자~!!!

반응형

'SCM > Git-GitHub' 카테고리의 다른 글

Remote Repository - git push  (2) 2012.03.04
Git Server - push + 한글  (1) 2012.02.26
Git Server - SSH  (2) 2012.02.23
Git Server - Local  (0) 2012.02.22
Protocol - Git Server  (0) 2012.02.20

이번에는 가장 많이 사용하는 프로토콜인 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 에는 적용하지 않는다.

 

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

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

반응형

'SCM > Git-GitHub' 카테고리의 다른 글

Git Server - push + 한글  (1) 2012.02.26
Git Server - Remote Connect  (0) 2012.02.25
Git Server - Local  (0) 2012.02.22
Protocol - Git Server  (0) 2012.02.20
Add last commit - git commit --amend  (0) 2012.02.16

작업을 위한 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을 사용하면 된다.

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

반응형

'SCM > Git-GitHub' 카테고리의 다른 글

Git Server - Remote Connect  (0) 2012.02.25
Git Server - SSH  (2) 2012.02.23
Protocol - Git Server  (0) 2012.02.20
Add last commit - git commit --amend  (0) 2012.02.16
Log - gitk  (0) 2012.02.15

작업을 위한 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를 적용하는 것을 추천하기에
그에 대해서 알아볼 것 같다. ^^

반응형

'SCM > Git-GitHub' 카테고리의 다른 글

Git Server - SSH  (2) 2012.02.23
Git Server - Local  (0) 2012.02.22
Add last commit - git commit --amend  (0) 2012.02.16
Log - gitk  (0) 2012.02.15
Log - git log  (2) 2012.02.14

이전 작업으로 돌아가는 실행취소가 아니라,
commit을 했는데, 미처 추가하지 못한 작업이 있어서 나중에 추가를 하고 싶은 경우에 대해서 설명하고자 한다.


1. Ready


오늘 설명할 기능을 위해서 상황을 준비했다.
위 스크린샷을 보면 알겠지만, 파일 2개를 수정한 상황으로 준비했다.


2. commit


2개의 파일 중에서 1개만 staging해서 commit을 했다고 해보자.

그런데, 나머지 파일도 방금 진행한 commit에 집어넣고 싶다면 어떻게 해야할까!?


3. git commit --amend


대상 파일을 'add' 하고선 'git commit --amend' 명령어를 실행하면,
comment 입력 에디터 화면이 뜨고, 저장을 하고 종료하면 마무리 된다.


4. log


로그를 확인해보면, 2개의 commit이 아니라 기존 commit에 반영이 되어있다는 것을 확인할 수 있다.

그리고 commit 기록 시간이 중요한데,
처음에 commit 시간이 그대로 반영 되어있다. 변화하지 않는다!




사용자가 실수를 했을 경우에 이를 만회할 수 있는 명령어들 중 하나에 대해서 설명을 하였다.
이미 commit을 한 것을 수정할 수 있다는 것은 살짝 논란거리가 될 수도 있다.

하지만, 나중에 살펴볼 Remote Server와의 관계를 생각하면 별 문제가 아닐 수도 있다.

중요한 것은 우선 실수를 하지 않는 것이다.
하지만, 만약 commit 할 때에 실수를 했다면 'git commit --amend'를 기억하면 더 좋겠지...!? ^^
반응형

'SCM > Git-GitHub' 카테고리의 다른 글

Git Server - Local  (0) 2012.02.22
Protocol - Git Server  (0) 2012.02.20
Log - gitk  (0) 2012.02.15
Log - git log  (2) 2012.02.14
Move file - git mv  (0) 2012.02.13

앞에서 'git log'를 통해서 로그를 확인했는데,
git 에서 로그를 보다 편하게 볼 수 있는 도구를 제공해준다.

바로 "gitk"


1. Error


$ gitk

'gitk'를 실행하면, 에러가 발생할 수도 있다.
'gitk'는 Tcl/Tk 기반의 프로그램인데, 'Tcl/Tk'가 설치되어있지 않아서 발생하는 에러이다.


$ sudo apt-get install tk

관련 패키지를 설치하면 위 에러는 해결이 된다.


2. gitk


$ gitk

'gitk'는 기본적인 비주얼 'git log' 도구이다.

앞에서 살펴본 커맨드 환경에서의 'git log'에서 했던 대부분의 것들을 GUI 환경에서 확인할 수 있다.


가볍게 여기까지~

반응형

'SCM > Git-GitHub' 카테고리의 다른 글

Protocol - Git Server  (0) 2012.02.20
Add last commit - git commit --amend  (0) 2012.02.16
Log - git log  (2) 2012.02.14
Move file - git mv  (0) 2012.02.13
Upgrade GIt (in Ubuntu)  (0) 2012.02.13

+ Recent posts