Git의 발음

   - 기트
   - 깃
   - 지트
   - 짓


이와 관련된 공식입장이 있는데,
현재 사이트 접속이 안되어 확인이 안된다(예전에 봤는데 기억이 가물가물).
   - http://git.wiki.kernel.org/index.php/GitFaq#Why_the_.27git.27_name.3F
그런데, 위 위키 페이지는 사라졌다. 이런...


보통 일반적으로 "깃"이라고 발음하고 있다.
나도 그렇게 발음하고 있고,
현업에서 근무하고 있는 주위의 다른 사람들도 그렇게 발음하고 있다.
KLDP에서도 그렇게 의견이 수렴되었다.


최근에 결정적인 증거(?)도 찾았다!!
리누즈 토발즈 아저씨도 깃으로 발음을 하고 있다.

   - http://www.youtube.com/watch?v=4XpnKHJAok8


결론! "깃"이라고 발음하면 된다.

[ 참고 ]
http://kldp.org/node/113721
반응형

Git에 대해서 소개하는 글 중에서 가장 와닿는 내용이 있다.

'Linux Kernel'의 형상관리를 위해서 사용하는 도구이며
'리누스 투르발스(Linus Benedict Torvalds)'가 직접 만들고 있는 도구


그런데, 여기에서 궁금증이 생겼다.

Git의 역사가 Kernel에 비해서 훨씬 짧은데,
그 이전에는 뭘 사용했었지!?

CVS?! Subversion?!


그래서 알아봤는데,
다른 도구들과는 달리 이에 대해서
공식적인 입장은 물론이고
다양한 이야기를 확인할 수 있었다.


1999년도에 Linux Power PC에서 사용하기 시작한 'BitKeeper'는
리누스가 "Best Tool For The Job"라며
2002년도부터 Kernel의 mainline에 적용하였다.

2002년도 이후 Kernel 개발 속도가
엄청 증가한 배경에
BitKeeper가 기여했다는 점은
아무도 반론할 수 없을 것이다.

BitKeeper는 상용 제품이다.
다만, Linux Kernel을 위해서(도움도 받았으니)
Free 버전을 계속 개발 해주고 있었다.

하지만, 오픈소스 진영의 대표주자격인 Kernel에서
상용 제품을 사용하는 것에 대한 비판이 많았던 것 같다.

하지만, 분산 개발을 제대로 지원하는
Linux Kernel 개발에 적합한 다른 대안 도구가
없었기에 그대로 사용할 수 밖에 없었다.

그러던 중, BitKeeper에 대한 Reverse-Engineer 시도가 있었고
경고를 했음에도 두 번 더 발각(?) 되면서
BitKeeper의 무료 버전 개발이 중단 되게 된다.

이 부분에 대해서 많은 이야기가 오가는데...
결론적으로

BitKeeper의 입장에서는
매년 $50,000 정도씩을 투자해서
Free로 제공해주고 있는데
그런 우리의 제품을 reverse engineer를 해서
기술을 빼가다니 너네 괘씸해!
이제 안줘!!!

오픈소스 커뮤니티 입장에서는
Free로 풀린거면 자유롭게 쓸 수 있는거지
왜 시비야~!!

하지만, BitKeeper 입장에서는
돈 안받고 쓸 수 있게 해준거지,
너네 맘대로 손대라고 한 것이 아니야~!!!

뭐 이렇게 정리가 되는 것 같다.



이렇게 되어 BitKeeper가 아닌
대안을 찾아야 하는 상황이 되었는데..

마땅한 대안이 없자,
직접 만들어 버리게 된다.

그것이 바로 Git 이다!!!



그것도 '리누스'아저씨가 주도하여
개발을 하다니...



그 유명한 '리누스' 아저씨가 개발을 하고,
운영체제의 양대 산맥 중 하나인
리눅스 커널을 개발하는데 사용중인 도구이며,

최근 모바일의 가장 뜨거운 핫이슈인
구글의 안드로이드도 사용하는 도구!!!

바로,
"GIt"
이다.


[ 참고 ]
http://en.wikipedia.org/wiki/Git_(software)
http://kerneltrap.org/node/4966
http://www.pcworld.idg.com.au/article/129776/after_controversy_torvalds_begins_work_git_/
반응형

'Git'이라는 '버전 관리 도구'를 언급하면 바로 따라오는 말이 있다.

- 리누스 투르발스 (Linus Benedict Torvalds, 위키피디아 기준 발음)
- 리눅스 커널 (Linux Kernel)
- 안드로이드 (Android)
- 분산 버전 관리 시스템 (Distributed Version Control System, DVCS)



다른 것들은 다음에 기회가 있으면 이야기하도록 하고,
여기에서는 '분산 버전 관리 시스템'에 대해서만 이야기를 해보고자 한다.



소프트웨어 형상관리의 흐름을 살펴보면,

로컬에서 파일시스템 기반으로 형상관리를 하다가,
네트워크 기반의 중앙집중식으로 관리를 하고,
최근에는 분산형 관리가 유행이다.



도구로 따지면,
'버전 관리 도구'의 고전작품인 'CVS'
'버전 관리 도구'의 대중화를 이끈 'Subversion'

이들과 'Git'이 차별점을 보여주는 부분이 바로 '분산 (Distribute)'이다.





컴퓨터 세상은 우리가 살아가는 사람들의 세상과 밀접하다.

C++을 통해서 우리에게 알려진 객체지향(Object-Oriented)이라는 것도
컴퓨터 언어에만 있는 것이 아니라
세상을 바라보는 관점에 대한 철학의 산물인 것처럼

분산 처리라는 것도 신경망 모델 중 하나로 개념화되어
일반적으로 부하가 걸리는 것을 해결하기 위한 방안으로
나누어 처리하는 것을 의미하는 아주 대중화된 방법이다.

말단 처리 장치의 능력이 좋아지고
네트워크가 잘 이루어진 상황에서는
당연한 수순으로 집중처리에서 분산처리로 변화하게 되는 것이다.





'CVS'와 'Subversion'과 같은 기존의 '중앙 집중식 버전 관리 도구'
'서버-클라이언트 (Server-Client)' 구조를 따른다.

'서버'를 구축해 놓고 사용자는 '클라이언트'로 붙어서 작업을 하는 방식이다.

이러한 구조에서 발생하는 문제 중에서 가장 큰 것은
'서버'가 없으면 '클라이언트'는 작업을 할 수 없다는 점이다.

다른 문제로는 '중앙 집중식 버전 관리 도구'의 장점이자 단점인데,
시스템을 구성하는데 단순하고 쉽게 할 수 있는 반면에
다양한 '워크 플로우(Work Flow)'를 구현하는데에 한계가 있을 수 밖에 없다.

실제 현업에서 이러한 '중앙 집중식 버전 관리 시스템'을 사용할 때
피부에 와닿는 문제는 협업을 할 때에 있었다.
특히 해외 연구소들... 더욱 더 특히 인도와 같이 느린 네트웍...




'중앙 집중식 버전 관리 시스템'의 경우를 예를 들어보자,
서버를 구축하는 것도 쉽고 시스템을 구성하는 것도 쉽고
한 곳에 모여서 열심히 작업을 할 때에는 아무런 문제도 없다.

그러던 중 해외의 연구소와 협업을 하게 되면서 문제가 발생한다.

그냥 기존과 같이 새로 계정 발급해주고 국내 서버에 붙어서
협업을 하게 하는데 해외쪽의 네트웍 속도가 느려서
제대로 check-out/in이 되지 않는 경우가 발생하는 것이다.

즉, 소스를 다운 받는데 네트웍이 느리다보니 종종 실패를 하게 되고,
더 큰 문제는 작업한 내용을 서버로 올릴 때 실패를 하는 경우이다.

실패를 하는 것은 그나마 나은 경우이고,
에러가 없었는데 파일 일부를 누락하게 되면 정말 괴롭게 된다.

이 모든 원인은 느린 네트웍 속도.

특히 관리하는 소스 코드의 용량이 클 경우에는
추가적인 더더욱 심각한 문제가 발생하게 된다.


이를 극복하기 위한 흔한 방법은
'프록시 서버(Proxy Server)'를 원격지 가까운 곳에 두는 것이다.

그리고는 메인 서버와 '동기화(Synchronization)'를 하도록 하면 된다.

보통은 이와 같은 방법으로 이와 같은 상황을 해결하지만,
동기화 과정에서 많은 문제가 발생하는 것을 완전히 피할 수는 없다.



이러한 것을 극복하기 위한 것이 바로
"분산 버전 관리"이다!

서버에서 check-out을 하게 되면
서버와 똑같은 내용을 전부 클라이언트가 갖게 된다.
즉, 클라이언트가 서버가 될 수 있는 것이다.

'로컬(local)'에 서버 복사본을 구축해버리면,
서버와 연결되지 않아도 혼자서 commit을 할 수 있다.

필요할 때에 필요한 내용만 서버로 보낼 수가 있다.

'프록시 서버'와 유사하면서도 또 다른 구성이다.

"Git"과 같은 "분산 버전 관리 도구"에서
기본적으로 손쉽게 '복사본(clone)'을 구축할 수 있게 함으로써
정말 다양한 '워크 플로우'를 구축할 수 있게 되었다.

정말 유연한 시스템을 구축할 수 있도록 도와주는 것인데,
이러한 유연성이 부담스러울 경우에는
기존 방식과 같은 타이트한 워크 플로우를 구성할 수도 있다.

비록 "Git"이 지향하는 '분산 버전 관리'의 모습은
'병렬 분산 처리 (Parallel Distributed Processing, PDP)'이지만,
사용자가 원하는 워크 플로우를 구성할 수 있다는 점이 중요하다.




'Git'의 명령어들을 공부하는 것도 중요하지만,
더욱 중요한 것은 'Git'을 이용하여 어떻게 작업을 할 것인지에 대해서이다.

'C언어'를 공부하는 것과 마찬가지인 것이다.
문법을 모두 공부했다고 해서 끝나는 것이 아니고
어떻게 프로그램을 만들 것인지에 대해서 공부해야하는 것처럼 말이다.


실제로 'Git'으로 이를 어떻게 사용할 수 있는지는
앞으로 차차 살펴보도록 하자.



[ 참조 ]
리누스 투르발스 - http://ko.wikipedia.org/wiki/%EB%A6%AC%EB%88%84%EC%8A%A4_%ED%86%A0%EB%B0%9C%EC%A6%88
분산 버전 관리 - http://ko.wikipedia.org/wiki/%EB%B6%84%EC%82%B0_%EB%B2%84%EC%A0%84_%EA%B4%80%EB%A6%AC_%EC%8B%9C%EC%8A%A4%ED%85%9C
인지과학 - http://terms.naver.com/entry.nhn?docId=8403
분산 버전 제어 시스템 소개 - http://www.ibm.com/developerworks/kr/library/au-dist_ver_control/
Reversion Control System - http://en.wikipedia.org/wiki/Revision_control_software
반응형

[ 한글 ]
형상 관리 (소프트웨어 형상 관리)
버전 관리 (소프트웨어 버전 관리)
소스 관리 (소스 코드 관리)


[ 영어 ]
Version Control
Revision Control
Source Control
Source Code Management (SCM)
Software Version Management
Software Configuration Management (SCM)




Subversion, Git, ClearCase 등과 같은 도구를 통해서 (또는 도구가 없더라도)
소스 코드, 문서, 결과물 등을 번호(버전)를 사용하여
관리하는 것을 무엇이라고 지칭해야 할까?



소프트웨어 공학(Software Engineering)이라는 학문은
개인적으로 '공학계의 인문학'이라고 여겨진다.

바꿔말하면 무엇을 정의하는 것이 어려우며,
정답이 없는 경우가 대부분이라는 말이다.



최근 아이폰이나 안드로이드로 인하여
대중화 되어버린 "플랫폼(Platform)"이라는 것을 보아도
분야마다 사람마다 그 정의가 전부 다를 수밖에 없다.

시험 문제로 "플랫폼의 정의를 쓰시오"라고
나오면 정말 당황스러울 것 같다.



이번의 경우는 조금은 색다른 경우인데,
이것을 지칭하는 용어가 너무 많아서 문제가 된다.

같은 것을 지칭하면서
다들 다른 용어를 사용하고 있는 것이다.



일반적으로는
Subversion, Git 과 같은 것을 지칭할 때에는
"버전 관리 도구 (Version Control Tool)"
라고 한다.

그러한 버전 관리 도구를 사용하여 구축한 시스템은
"버전 관리 시스템 (Version Control System, VCS)"
이라고 부르곤 한다.



소프트웨어 공학을 공부하다 보면
상당 부분의 개념이 산업 공학 특히 생산 공학에
그 기반을 두고 있는 것을 알 수 있다.

그로 인하여, 버전 관리를 포괄하는 다른 용어가 나오는데
"형상 관리 (Configuration Management)"
가 그것이다.


그 중에서 소프트웨어 분야에 대해서는
"소프트웨어 형상 관리 (Software Configuration Management, SCM)"
라고 부르고 있다.



'소프트웨어 형상 관리'는
'버전 관리'를 포함하는 더 크게 포괄하는 의미다.

'소프트웨어 생명 주기 (Software Life Cycle)' 전반에 걸쳐서
개발 환경을 비롯한 전반적인 모든  형상물들에 대한
'변경 관리'를 위한 모든 활동을 의미한다.


형상 식별, 버전 제어, 변경 제어, 형상 감사, 형상 상태 보고 등
어려운 말로 소프트웨어 형상 관리에 대한 정의들이 있긴 하다.



어려운 이야기를 계속 하고자 하는 것은 아니다.

다만, '소프트웨어 형상 관리'라는 것이
곧 '소프트웨어 버전 관리'를 의미하는 것은 아니라는
말을 하고 싶은 것이다.

'소프트웨어 형상 관리'의 범주 안에
'소프트웨어 버전 관리'가 포함이 되어 있을 뿐이다.



문제는 이러한 것을 실무자들도 분명히 알고 있으면서도
아니, 최소한 어렴풋하게 알고 있으면서도
이 두 가지 용어를 그냥 동의어로 사용하고 있다.

또 사실 동의어로 사용해버린다고 하여
꼭 틀렸다고 할 수 없는 것도 사실이다.
( 우기면 뭐 그렇다고 할 수 밖에 없는 것이 현실! )


단순히 소스 코드에 대해서만 관리한다고 하면
"버전 관리"
소스 코드를 비롯하여 개발 환경, 빌드, 기타 등등까지라면
"형상 관리"
라고 지칭하기로 하자.


우리가 앞으로 계속 살펴볼 "Git"은
기본적으로 "버전 관리 도구"이다!


하지만, Git을 기반으로 하여 소프트웨어를 관리하는 시스템을 만든다면
그것은
"소프트웨어 형상 관리 시스템"
이라고 부르기로 하자.


[ 참고 ]
http://ko.wikipedia.org/wiki/%EB%B2%84%EC%A0%84_%EA%B4%80%EB%A6%AC
http://ko.wikipedia.org/wiki/%ED%98%95%EC%83%81_%EA%B4%80%EB%A6%AC
정보통신단체 표준, TTA.IE-828, 소프트웨어 형상 관리 계획 표준
반응형

나름의 목적을 가지고 열심히 포스팅을 하고 있는 블로그이지만,
댓글 하나 없이 몇 날 몇 일이 흐르면 조금 외롭게 되는데, 최근 댓글을 잘 달아주시는 분들이 생겨서 너무 좋다.
그런 감사한 분들 중 한 분이 알고 싶으시다는 내용이기도 하고 내가 하려고 했던 내용이기도 하다.


EGit에 대한 정보는 다음을 참조했다.
     - http://wiki.eclipse.org/EGit/User_Guide


여기에서 알아보고자 하는 내용은 바로 "Eclipse"에서 Git 사용하기!!!



01. Eclipse

     - 개발 환경으로 가장 유명한 도구 중 하나임은 다시 설명할 필요가 없을 것이다.
     - Java 기반의 프로그램으로써 한계를 고스란히 안고 있는 것 또한 사실이다. 무겁다는 말이다.


     - JDK 설치 먼저 해야하는 것은 당연하고...
        → http://www.oracle.com/technetwork/java/javase/downloads/index.html
     - Eclipse 역시 다운 받아서 설치, 아니 압축을 풀어주면 된다.
        → http://www.eclipse.org/downloads/



02. 확인

     - Eclipse에서 사용할 수 있는 Git plugin은 크게 JGit 과 EGit 두 가지가 있다.
     - 그런데, 예전에는 이 plug-in들을 별도로 설치를 해주어야 했지만 최근들어 이걸 기본적으로 제공해주고 있다.

     - 하지만, Eclipse Classic을 설치하면 포함이 안되어있다.


     - Import 하는 부분에 CVS는 있지만, Git은 안보인다.






03. 설치

     - GIt 관련 Plug-in이 내장되어있지는 않지만, 제공은 해주고 있다.


     - [ Help ] → [ Install New Software ]
     - Work with 부분에서 "Indigo"를 골라주자.


     - "Collaboration" 항목을 확장해서 "Eclipse EGit"을 선택하면 된다. 나머지 과정은 그냥 쓕쓕~


     - 설치를 마치고 나면, 재시작을 물어본다. 당연히 재시작해주면 된다.




04. Preference

     - EGit Plug-in의 환경 설정을 하자.


     - [ Window ] → [ Preference ]


     - "Team" → "Git" 항목을 선택하면 위와 같은 화면이 나온다.



05. User Settings

     - 개발 PC에서 Git을 사용하기 위해 환경을 맞출 때에 제일 먼저 해야할 것은 내가 누구인지 알려주는 것이다.


     - 기본적인 환경 설정에 대해서 잘 확인하고 입력해놓자.



06. SSH public key

     - 우리는 지금 Gitolite를 사용하고 있는 환경에 대해서 알아보고 있으므로 공개키를 등록해보자.


     - [ Git ] 항목이 아니라 [ General ] 항목에서 "Network Connections - SSH2" 부분에서 설정을 한다.
     - 앞 포스팅에서 "Git Bash"를 통해 "ssh-keygen"으로 키를 만들었으면 위와 같은 설정을 그대로 사용하면 된다.
     - 물론 만약 다른 경로에 위치하고 있다면, 그에 맞게 변경하면 된다.



07. Import

     - 이제 Remote Repository에 있는 프로젝트를 가져오는 과정에 대해서 알아보자.


     - [ File - Import ] 메뉴를 선택해서 나오는 창을 살펴보면 "Git"이라는 항목이 새로 나온 것이 확인된다.
     - "Projects from Git"을 선택하면 된다.


     - Remote Repository로 부터 받아올 것이니 당연히 "URI"를 선택하면 된다.


     - URI를 작성할 때에 바로 URI를 작성할 필요없이, 밑의 항목들을 입력하면 자동으로 URI가 완성된다.
     - Host, Repository path, Protocol(다시 한 번 ssh 선택해주면 된다), User를 입력해주자.
     - Password는 비워두면 된다. 왜냐하면, 우리는 SSH 공개키를 등록했기 때문이다.


     - 성공적으로 연결이 되면 branch를 선택하는 창이 나온다.


     - 어디에다가 파일들을 받을 것인지, 어느 branch로 시작을 할 것인지, Remote 이름을 확인하자.


     - 그러면 위와 같이 cloning 작업을 수행한다.


     - 다 받아오게 되면 위와 같이 받아온 소스코드를 프로젝트와 어떻게 연결할 것인지를 묻는 화면이 나온다.
     - 일단은 위 스크린샷과 같이 새로운 프로젝트로 만들어보자.


     - 받아온 소스코드 성격에 따라서 프로젝트 타입을 골라주면 된다.


     - 그리고, 프로젝트 名을 적어주면 된다.


     - 그러면, 이제 마무리가 되어야 하는데...

     - 뭔가 이상하지 않은가??????



08. Directory

     - 그렇다. 프로젝트를 만들었는데, 파일들이 안보인다.

     - 앞에서 살펴본 부분에서 Directory들을 한 번 살펴보면 이상한 원인이 보일 것이다.


     - 프로젝트를 만들 때 location을 확인해야 한다.
     - Remote Repository를 clone 받을 때에 지정했던 경로와 동일하게 설정을 해주어야 하는 것이다.


     - 이번에는 제대로 파일들이 보일 것이다!



09. Share Project

     - 그러면 Git 관련 작업을 할 때엔 어떻게 해야할까?!


     - [ Team - Share Project ]를 실행하면 창이 하나 나오는데...


     - 경고 메시지가 나온다. "HOME" 이라는 이름의 환경변수를 설정해야 한다는 말이다.

     - 하지만, 안내메시지처럼 알아서 기본 경로를 잘 잡아준다.
     - 귀찮으면 "Do not show again"을 체크함으로써 끝~

     - 공식 가이드에 의하면 Windows 7 환경에서는 "Users" 디렉토리의 대소문자 오류가 있으니 참고~!!


     - [ Use or create repository in parent folder of project ]에 체크를 하고 "Finish"를 해주면 된다.


     - 모두 설정하고 나면 오른쪽 버튼의 "Team" 항목에 위 스크린샷과 같이 새로운 메뉴가 나타난다.




여기까지~~~~~~
Eclipse 환경에 대해서 너무 길게 포스팅한 것 같지만... 그래도 좀 아쉬운 부분도 있다.



오늘은 이 블로그를 통해서 좋은 인연을 맺게 된 분과 처음으로 만났다.
그로 인해서 너무나 감사한 기회를 얻게 될 것 같은데... 뭔가 정해지면 다시 또 공유해보겠다.

반응형

포스팅을 할 때 가장 즐거운 일은 댓글을 확인하는 것이다 ^^
이번에는 저에게 너무나 큰 기쁨을 주는 댓글을 통해 문의하신 것 중 하나에 대해서 포스팅 해보고자 한다.

Gitolite에 대해서 어려워 하시는 분들의 대부분은 Gitolite 때문이 아니라,
SSH에 대한 이해와 더불어 공개키(public key)에 대한 사항 때문에 어려움을 겪게 된다.


Windows에서 공개키 만들고 등록하는 것은 Linux 환경에서 하는 것과 거의 동일하다.
그래도 다시 한 번 되돌아 보는 의미로 살펴보면서 공개키에 대해서 같이 살펴보도록 하겠다.



1. 공개키 등록하기

     - 새로운 사용자, 지금 상황에서는 Windows XP 환경의 사용자가 등록을 하고 싶은 경우를 살펴보자.


     - 왼쪽 하단의 'chaniXP'라는 이름의 사용자가 공개키를 만들어서,
       왼쪽 상단의 gitolite 관리자에게 보내면, 그 관리자가 등록 및 설정을 하고,
       오른쪽의 Server에 push를 하면,
       chaniXP 사용자는 Server로부터 허용된 repositories를 clone 받을 수 있게 되는 것이다.

     - 여기서 중요한 점은 chaniXP라는 사용자는 Server의 계정이 아니다.
     - Gitolite를 사용하게 되면, Server에서는 'git-repo'라는 계정 하나만 있으면 된다.




2. Git Bash

     - Windows 환경에서 Git 설치하기를 하셨다면, Git Bash가 있을 것이다.


     - 무슨 말인지 모르겠다면, 다음 포스팅을 참조하면 된다.
     - http://whatwant.tistory.com/288





3. Windows에서 공개키 만들기

     - Linux 때와 마찬가지로 [ ssh-keygen ]을 실행하여 공개키를 만들어주자.


$ ssh-keygen

     - Windows 환경에서도 분명히 사용자 이름이 있으며, home directory는 존재한다.
     - 그냥 엔터만 쳐도 잘 만들어진다.




4. 공개키 보내기

     - Gitolite 관리자에게 공개키를 보내서 등록해달라고 해야한다.
     - 여기에서는 gitolite라는 계정에게 scp를 통해서 공개키를 보내주도록 하겠다.



     - 중요한 점은 이전에도 한 번 언급했지만, 일반적으로 [ 계정명.pub ] 형식의 파일명을 사용한다는 것이다.




5. Gitolite 관리자

     - 이제부터는 Gitolite 관리자가 해야하는 일이다.

     - 우선은 새로운 파일이 잘 들어왔는지 확인을 하고, 그 계정에게 권한을 부여해주면 된다.


$ nano ./conf/gitolite.conf

     - ./keydir directory 안에 [ chaniXP.pub ]라는 파일이 잘 들어왔는지 확인을 하고,
     - [ ./conf/gitolite.conf ] 환경 파일을 수정해주면 된다.


     - 공개키를 등록한다해도, 그 계정이 어느 repository에 권한을 갖는지 정해주지 않는다면 무용지물이다.




6. push

     - 제일 중요한 과정이다. 바로 서버에 해당 정보들을 보내주어야 모든 것이 이루어진다.


$ git add ./keydir/chaniXP.pub
$ git commit -a -m "add user - chaniXP"
$ git push

     - 위 스크린샷과 명령어 정리한 내용과 차이가 있다.

     - 정말 종종 실수하는 부분인데, 기존에 등록된 파일의 수정이 아니라 새로운 파일이 등록되었을 경우에는
        [ git commit -a -m "..." ] 명령으로 처리가 되지 않는다. 별도로 등록을 해주어야 하는 것이다!!!!!
     - 이 부분만 주의해서 정리하고 push 해주면 모든 것은 끝난다!!!




강원도 솔비치로 2박3일 가족여행을 다녀오자마자 내 방에 처박혀서 포스팅을 하고 있으니,
우리 아가와 와이프가 째려본다.... ㅋㅋㅋ ^^

솔비치 호텔에서 2박 모두 했는데 바로 앞에 바다가 있어서 아가랑 놀러가기에는 정말 좋은 것 같다.
다만, 아직까지는 물이 차가워서 모래놀이 위주로 했지만...

다음에는 호텔이 아니라 콘도로 예약을 해야겠다 ^___^

반응형

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

GitHub - Signup  (0) 2012.06.10
Gitolite in Eclipse ( 이클립스 환경에서 Gitolite 접근하기 )  (2) 2012.06.07
Rebase - 또 하나의 merge  (0) 2012.05.30
Gitolite - Personal Branches  (4) 2012.05.28
Gitolite - user, repo 추가하기  (14) 2012.05.26

Git의 기본적인 계정(권한) 관리는 SSH를 따라간다고 앞에서 지겹게 언급했다.

SSH가 훌륭한 놈이라는 것은 분명하지만,
계정 관리에 있어서 부족함이 있는 것 또한 분명하다.

Git에 있어서도 다양하고 디테일한 권한 설정 등이 필요한데,
이 부분을 SSH는 충분히 채워주지 못하고 있다.

그래서, Git을 위한 계정(권한) 관리 도구들이 계속 나타나고 있다.

과거에는 Gitosis 라는 것을 주로 사용했으나 기능이나 사용상의 편의성에 있어서 부족함이 보여서
새로운 Gitolite 라는 것이 나타났고, 최근에는 거의 대부분 Gitolite를 사용하고 있다.

사실 일반적인 경우 Gitosis만 가지고도 대부분 처리가 가능하나,
왠지 더 최근의 보다 더 막강한 Gitolite를 적용하곤 하는 것도 없지 않아 있는 것 같다.
물론 나의 경우에도 마찬가지다! 최신병에 걸린 죄로.... Gitolite에 대해서 연구를 해보겠다!!!




Gitolite를 설치하는 방법은 당연하게도 패키지 설치와 소스 설치가 있고...
여기에서는 소스를 가지고 설치하는 과정으로 설명을 할 것이다.


[ 전면수정 ]
   - 내가 바보같아서인지, 이 놈의 Gitolite에 대해서 친절하게 설명해 놓은 자료가 안보인다.
   - 가끔 친절한척 자세히 적어놓은 것들이 있지만, 따라하다보면 대체 뭘하는 것인지 모르겠는 그런 것이 대부분이다.
   - 더더욱 힘들게 하는 것은 Gitolite가 최근 g2 버전에서 g3로 바뀌면서 설치 과정들이 바뀌었다.
   - 그래서 예전 기억을 더듬어 차근차근 포스팅을 해나가다가... 좌절! 결국 대폭 수정 작업!!! 짜증 확!!! ㅠㅠ




1. Gitolite


     - Gitolite 프로젝트의 홈페이지는 아래와 같다.
          ▷ https://github.com/sitaramc/gitolite
     - 설치 과정에 대한 매뉴얼은 아래와 같다.
          ▷ http://sitaramc.github.com/gitolite/install.html
     - 계정 관리 등에 대해서 요약(?)을 한글로 보고 싶다면 아래 주소로 가라.
          ▷ https://github.com/progit/progit/blob/master/ko/04-git-server/01-chapter4.markdown



2. 시스템(계정) 구성

     - Gitolite를 설치하는 환경을 위해 어떻게 구성해야하는지 살펴보자.


     - 꼭 위와 같이 구성해야하는 것은 절대 아니다.
     - 아래 설명하는 내용을 잘 읽어보고 어떻게 구성해야하는지 각자 결정하면 된다.

     - 위의 직사각형은 각 계정을 의미한다.
     - [ git-repo ] 계정은 Git repository를 운영하기 위한 계정이다.
     - [ gitolite ] 계정은 Gitolite를 관리하기 위한 관리자 계정이다.
     - [ user ] 계정은 그냥 여러분이 사용하는 Ubuntu의 기본 계정이다.

     - 위 그림에 대한 설명은 아래 내용들을 하나씩 따라하면 알 수 있을 것이다.



3. 계정 생성

     - SSH 환경에서 여러 개발자들을 지원해주기 위해서는 Linux 계정을 그 숫자만큼 만들어줘야 했다.
     - Gitolite를 적용하게 되면 Linux 계정을 만들어주지 않고도 Git 계정을 만들어 줄 수 있다.
     - 대표 계정 하나로 나머지를 모두 커버하는 것이다.


$ sudo adduser gitolite
$ sudo adduser git-repo

     - [ gitolite, git-repo ]라는 계정을 추가해주자.



4. Public Key 등록

     - 현재 작업중인 계정에서 다른 계정에 접근하기 위해 Public-Key를 등록해주자.


     - 지금 사용중인 user의 계정에서 gitolite, git-repo 계정으로 ssh 접근을 바로(패스워드 없이) 하기 위해서
       user 계정의 공개키를 넣어주는 것이다.


$ ssh-keygen
$ ls -al ~/.ssh/

     - [ ~/.ssh/ ] 계정의 홈디렉토리 밑에 있는 '.ssh/' 디렉토리 밑의 파일들을 우선 확인하고,
     - [ id_rsa ], [ id_rsa.pub ] 파일들이 안보이면 [ ssh-keygen ]으로 생성을 해주면 된다.

 

$ ssh-copy-id -i ~/.ssh/id_rsa.pub gitolite@localhost
$ ssh-copy-id -i ~/.ssh/id_rsa.pub git-repo@localhost


     - 지금 현재 계정의 공개키를 gitolite, git-repo 계정에 넣어주기 위한 명령이다.


     - 잘 되었는지 검증해보기 위해서는 아래와 같이 직접 ssh 접속을 해보면 안다.

     - 암호를 묻는 과정이 사라졌다.
     - gitolite 계정의 [ ~/.ssh/ ] 경로를 살펴보면 [ authorized_keys ] 파일이 보일 것이다!



5. Gitolite 다운로드 받기

     - 위와같이 계정들을 생성하고 준비를 하고...이제 Gitolite를 설치해보자.
     - 그런데, 어디에 Gitolite를 설치해야할까?!

     - 정답은 repository를 저장할 곳이다! 즉, [ git-repo ] 계정에서 설치를 해야하는 것이다.

 


     - [ git-repo ] 계정에서 Gitolite를 다운로드 받고 설치하면 된다.
 



     - 위 사이트에서 경로를 확인하고... 진행을 계속 해보자.



   - [ git-repo ] 계정으로 작업을 하기 위해서 해당 계정으로 접속한다.
   - [ git-repo ]의 홈디렉토리에서 Gitolite를 clone하면 된다.

   - 그런데, 여기에서 중요한 점을 하나 집고 넘어가야 한다.
   - 웹에서 검색이 되는 Gitolite의 설치가이드 대부분과 지금 현재 상황이 맞지 않는다는 점이다.
   - 그 이유는 버전이 틀리다!!! 기존 Gitolite 대부분은 "g2" 버전이고, 지금은 "g3"다.
   - 그래서 설치 스크립트가 틀리다.
   - 2012.04.17에 g3가 릴리스가 되어서인지, 이와 관련한 자료는 거의 없다.



6. install

     - 다운로드 받은 Gitolite를 설치해보자.


$ ./gitolite/install

     - 그냥 'install'만 실행하면 일단 끝이다.

     - 만약 다른 디렉토리에 설치하고 싶으면 [ ./gitolite/install -to /srv/install/gitolite ]와 같이 사용한다.
     - 여기에서 설치하는 것은 실행할 수 있는 binary들이다.

     - 이제 이어서 'setup'을 해야하는데, 관리자 계정의 공개키가 필요하다.
     - 앞에서 만든 계정 중에서 우리는 [ gitolite ]라는 이름으로 관리자 계정을 만들어 놓았다.


$ ssh gitolite@localhost
$ ssh-keygen

     - 여기서 생성한 공개키를 전송해야한다.



     - [ gitolite ]의 공개키를 [ git-repo ] 계정 어딘가로 전송을 하고자 한다.

     - 위의 경우 ~/.ssh/ 밑에 위치했는데, 꼭 그곳이 아니어도 된다.
     - 관리자로 사용할 계정의 공개키가 Gitolite 설치과정에서 필요로 해서 이렇게 하는 것이다.


$ ./gitolite/src/gitolite setup -pk ./.ssh/gitolite.pub

     - install 후에 사용할 수 있게 된 [ ./gitolite/src/gitolite ] 명령어를 이용하여 setup을 하는데,
     - [ gitolite ] 계정의 공개키를 관리자로 등록하는 것이다.

     - Gitolite는 하나의 repository로 관리를 하게 된다. 위 화면에서 보는 바와 같이 [ gitolite-admin.git ]이 그것이다.
     - 해당 repository에 자료를 넣을 수 있는 관리자는 방금 전에 등록한 공개키로 인하여 [ gitolite ] 계정이다.

     - 친절하게도 테스트 해볼 수 있게 [ testing.git ] repository도 제공을 해준다.



7. clone

     - [ gitolite-admin.git ] repository를 clone 받아서 확인을 해보도록 하겠다.


$ ssh gitolite@localhost
$ mkdir repositories

     - Gitolite에 관리자로 등록시킨 [ gitolite ] 계정으로 접속하자.
     - clone 받을 디렉토리도 'repositories'라는 이름으로 만들어두자.

▶ 여기에서 Gitolite를 처음 접하는 분들을 위한 질문~!!!!!!!
     - 위와 같이 만든 [ Gitolite를 적용한 Git ]에 어떻게 접근을 할까?!

▷ 정답은 대표 계정 1개로 접근을 한다!
     - 이 포스팅 내용대로라면 여기에서는 [ git-repo ] 계정


     - [ gitolite ] 계정이 [ git-repo ] 계정에 접근을 하려고 하면,
     - 'gitolite' 계정의 private key에 대응하는 public key를 찾는데,
     - [ Gitolite ]가 이 부분에 개입을 해서 등록된 public key를 기반으로 권한을 확인하고
     - repository에 대한 접근 권한을 조정한다.

     - 이 부분에 대해서 오랫동안 고민해보질 못해서인지 쉽게 설명은 안되는데, 위의 글과 그림을 잘 봐보면....^^

     - 일단, clone을 해보자.


$ cd ~/repositories
$ git clone git-repo@localhost:gitolite-admin.git


     - 지금 현재 사용자 계정은 [ gitolite ]이다.
     - Gitolite에 관리자로 public key를 등록한 계정도 [ gitolite ]이다.
     - 그런데, clone을 할 때 [ git-repo ] 계정으로 접근을 했다. 응?!

     - 위에서 말한바와 같이, Gitolite를 사용할 때에는 무조건 대표 계정을 사용한다.

     - 그러면, 다른 계정에서 똑같이 하면 어떻게 될까?


     - Gitolite에 별도로 계정 등록을 하지 않은 사용자 chani 계정에서 접근을 할 때인데... 당연히 접속 불가~!!!


     - [ chani ] 계정이 'git-repo' 계정으로 접근을 하지만,
     - Gitolite가 등록된 공개키를 확인을 하는데 등록된 것이 없기에 접근을 거부하게 된다.




이번 포스팅을 하면서 너무 오랜 시간이 걸렸고, (헷갈리기도 하고 주말에 열심히 놀기도 하고 사고도 있고.....)
포스팅 내용 자체도 너무 길어지는 관계로 여기까지만해서 설치에 대해서 마무리!!!

계정 관리하는 것이나, admin 환경 설정하는 것이나 그러한 것들은 다음 포스팅으로.......


아자~!!! 오늘 두산 이겼다.... 그런데, 좀 부끄럽게 이겼다.... 프로들이 어이없는 실수들을 서로 남발하는....ㅋㅋㅋ

반응형

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

Git 계정 관리 - Gitolite's Repository  (4) 2012.05.20
Git 계정 관리 - Gitolite 설정하기  (3) 2012.05.19
GitWeb + Nginx  (0) 2012.05.09
SSH Public Key - SSH 공개키  (0) 2012.05.04
Git Branch (브랜치) - Remote Ⅲ (생성, track)  (0) 2012.05.01

Git Repository를 셋팅해놓고 보면 자주 나오는 요청 사항 중 하나가 바로 Web 환경이다.
소스 코드 등을 Web 환경에서 제공해주길 바라는 것이다.


Git은 기본적으로 GitWeb이라는 것을 제공해준다.
Redmine을 사용한다면 GitWeb 대신 Redmine에서 제공해주는 '저장소' 메뉴를 활용할 수도 있다.


여기에서는 GitWeb을 설치하는 방법을 알아보겠다.
단, 일반적인 설치 방법과 다른 점은 웹서버를 Apache가 아니라 Nginx를 이용해보겠다.

그렇다고, 뭐가 많이 다른 것은 아니다.
CGI만 구동할 수 있다면 어떤 웹서버를 사용해도 무관할 것으로 보인다.


1. build

   - 일단은 Git의 Source Code가 필요하다.
   - 이번 기회에 Git 업그레이드도 할 겸 새로 다운로드 받아보자.



   - Git의 경우 major 업그레이드는 가끔이지만, Minor 업그레이드는 자주 올라오고 있다.

 


$ tar zxvf git-1.7.10.1.tar.gz
$ cd git-1.7.10.1/

$ make GITWEB_PROJECTROOT=/srv/repository prefix=/usr/local all
$ sudo make prefix=/usr/local install

   - 압축을 풀고, make를 진행하면 된다.
   - 기존과 다른 점은 [ GITWEB_PROJECTROOT=/srv/repository ] 옵션이 추가되었다.
     → repository가 있는 위치를 지정해주는 부분이다.
   - make 옵션의 제일 뒤에 [ all ]이 있는데, 모든 것으로 지정했기 때문에 GitWeb 관련 부분도 포함이 되어버린다.
     → GitWeb만을 위해 make 할 때에는 [ all ] 대신에 [ gitweb/gitweb.cgi ]라고 적어주면 된다.


$ git --version

   - 설치된 결과를 확인해보자.




2. copy

   - 생성한 파일들을 웹서버로 구동하기 위해 일단 위치 정리부터 해보자.


$ sudo cp -Rf gitweb /srv/www/

   - 우리가 관심이 있는 파일은 [ gitweb.cgi ]이다.



3. webrick

   - 잘 동작하는지 한 번 살펴보자.


$ git instaweb --httpd=webrick

   - 아무곳에서나 실행을 하면 위와 같이 에러가 발생을 한다.
   - git repository 안에서 실행을 하면 된다.


   - "bare1repo.git" 디렉토리 안에서 실행을 하지만, 그 상위 디렉토리에서 실행이 된다. (이유는 ???)


   - 정말 보기가 편하다. 'CLI' 환경에 비해서 다양한 정보를 보기가 너무 좋다.



4. Nginx

   - 이 블로그의 포스팅을 계속 보고 계시는 분들은 알겠지만, WAS로 Nginx를 계속 사용하고 있다.
   - Redmine, Munin 모두 Nginx를 기반으로 구동을 했었으니, GitWeb도 Nginx로 구동을 하고자 했다.

   - 그런데, 문제는 이쒸 정말 아우~ 정말 빡치게도.... Nginx와 GitWeb은 친하지 않다.

   - GitWeb이 'CGI'로 되어있는데, Nginx는 기본적으로 FastCGI를 지원하지 않는다.
   - 거기에다가 더욱 더 큰 문제는 기본적인 CGI가 아니라 Perl 기반으로 되어있는 GitWeb이다.


$ sudo apt-get install libfcgi-perl

   - Perl기반의 CGI 지원을 위해 [ libfcgi-perl ]을 설치해주자.


$ sudo apt-get install fcgiwrap spawn-fcgi

   - 추가적으로 2가지 더 설치를 해주자.


$ sudo nano /opt/nginx/conf/nginx.conf

    server {
        listen 9000;

        location @gitwebhandler {
            rewrite /gitweb /gitweb.cgi;
        }

        location /gitweb {
            alias /srv/www/gitweb;
            index gitweb.cgi;

            try_files $uri $uri/ @gitwebhandler;
            expires 10d;

            location ~* \.(css|png|gif|ico|jpe?g|js) {
                expires 31d;
            }

            location ~ .cgi$ {
                root /srv/www/gitweb;
                if (!-e $request_filename) { rewrite / /gitweb.cgi last; }
                expires off;

            #    fastcgi_pass unix:/var/run/fcgiwrap.socket;
                fastcgi_pass 127.0.0.1:8999;
                fastcgi_index gitweb.cgi;
            #    fastcgi_param SCRIPT_NAME $fastcgi_script_name;
                fastcgi_param SCRIPT_NAME gitweb.cgi;
            #    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param SCRIPT_FILENAME /srv/www/gitweb/gitweb.cgi;
                include /opt/nginx/conf/fastcgi_params;
            }
        }
    }

   - 위와 같이 하면 일단 구동은 할 수 있는데, 제대로 동작은 하지 않았다.
   - 첫 화면은 잘 나오는데, repository 등을 클릭했을 때 정상 동작하지 않는다.

   - 몇 일을 해결하려고 애를 썼는데, 해결이 안된 상태로 그냥 그대로 포스팅한다.




다른 진도를 나가야하는데, 여기에 너무 많은 시간을 투자하게 되어 해결하지 못하고 마무리 하게 되어 정말 아쉽다.
나중에라도 꼭 해결을 해보도록 하겠다.

Apache2 환경에서는 곧 추가하도록 하겠다.

이상~

반응형

+ Recent posts