빌드하기 위해 필요한 패키지들을 미리 설치합시다.

yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel gcc xmlto


asciidoc 은 직접 받아서 설치를 해야 한다.

$ cd /srv/install/asciidoc
wget http://pkgs.repoforge.org/asciidoc/asciidoc-8.6.8-1.el6.rfx.noarch.rpm
$  rpm -Uvh 
asciidoc-8.6.8-1.el6.rfx.noarch.rpm

git 소스파일을 내려 받아야겠죠?!

$ cd /srv/install/git
$ wget  http://git-core.googlecode.com/files/git-1.8.4.1.tar.gz
$ tar zxvf git-1.8.4.1.tar.gz
$ cd ./
git-1.8.4.1  


 Ubuntu에서 했던 것과 차이가 없죠 !?

$ make configure
$ ./configure --prefix=/usr/local
$ make all doc
$ sudo make install install-doc install-html

버전 확인 !

$ git --version


GIT 자동완성을 지원하기 위해서는...

우리 모두 Git으로 행복한 형상관리를...
반응형

형상관리 도구를 사용해야 하는 환경에서 종종 문의가 들어오는 내용 중 하나가 바로 IDE 지원 여부이다.
특히 개발자가 가장 많이 사용하는 IDE 라고 하면, MS Visual Studio와 Eclipse를 꼽을 수 있다.

Eclipse 환경에서는 EGit plugin을 사용하면 되고...
   - 참고 : http://whatwant.tistory.com/412

MS Visual Studio 환경에서는 최근 Microsoft 에서 공식 지원을 해주고 있다.
사실 필자는 Visual Studio를 거의 사용하지 않기에 이렇게 지원을 하고 있는지 전혀 모르고 있었다.


Visual Studio Tools for Git

   [ Requirements ]
      ▷ Visual Studio 2012
      ▷ Visual Studio 2012 Update 3

   [ Link ]
      ▷ http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c

   [ Screenshot ]



그런데, 이것 말고도 또 있긴 하다.

Git Source Control Provider
   - http://visualstudiogallery.msdn.microsoft.com/63a7e40d-4d71-4fbb-a23b-d262124b8f4c


사실 이런 도우미들을 사용할 필요 없이 그냥 윈도우즈 환경에서 Git을 설치해서 사용해도 큰 불편함이 없을거라 생각한다.
   - http://git-scm.com/downloads



나중에 기회가 되면 Visual Studio를 설치해서 테스트해보도록 하겠다~ (난 gcc가 좋은데... ㅠㅠ)
반응형

Git 계정 관리에 대해서 알아보면서 이미 한 번 SSH Public Key에 대해서 살펴보았었다.
   - http://whatwant.tistory.com/395


이번에는 예전에 살펴보지 못한 부분들에 대해서 알아보고자 한다.


1. Server : ssh daemon 설정

   - 만약 Git Server에서 Public Key로 접속하는 것을 막아버리고 싶으면 어떻게 해야 힐까?
   - [ /etc/ssh/sshd_config ] 파일을 살펴보면 된다.

PubkeyAuthentication yes

   - 그 외에도 다양한 설정들을 살펴볼 수 있고, 손 볼 수 있다.


2. Client : RSA vs DSA

   - SSH Public Key 파일을 생성할 때 보통 RSA 타입을 사용했다.
   - [ ssh-keygen ] 명령어를 보면 DSA 타입에 대해서도 나온다.
   - RSA는 무엇이고 DSA는 무엇일까?

   ※ 아래 내용은 위키피디아(http://ko.wikipedia.org/)의 내용을 많이 참고하고 있습니다.

   ① RSA
      - 1977년 로널드 라이베스트, 아디 샤미르, 레오널드 애들먼의 연구에 의해 체계화 된 공개키 암호시스템이다.
      - (Ron Rivest), (Adi Shamir), (Leonard Adleman) 3명 연구원의 이름 앞글자로 RSA 이름이 지어졌다.
      - 1983년에 발명자들이 소속되어 있던 MIT에 의해 미국에 특허로 등록되었고, 2000년 9월 21일에 그 특허가 만료되었다.
      - RSA 암호체계의 안정성은 큰 숫자를 소인수분해하는 것이 어렵다는 것에 기반을 두고 있다.

   ② DSA (Digital Signature Algorithm)
      - RSA와 마찬가지로 비대칭형 암호화 방식이다.
      - ElGamal 알고리즘을 이용하여 NIST(미국립표준기술연구소)에서 개발한 전자 서명방식이다.
      - 나중에 DSS(Digital Signature Standard)로 이름이 변경된다.
      - 보통 웹인증서에서 사용하는 방식이다.

   - 암호화 속도는 비슷하지만, 키 생성은 DSA가 빠르고 검증속도는 RSA가 빠르다.
   - RSA는 원문을 개인키로 암호화 해야 서명이 가능하지만, DSA는 그렇지 않다.
   - DSA는 전자서명 여부에 따라 예/아니오로 간단하게 사용한다.

   - 개인적으로 궁금한 것은 DSA가 RSA 보다 더 좋은 것인지 확인하고 싶었다.
   - 결론적으로는 뭐 그냥 그렇다. 그냥 RSA를 사용하게 하는 것이 무난하다는 판단이다.


3. SSH Public Key 활용하기

   - A 라는 사용자가 [ssh-keygen -t rsa ] 명령으로 [ id_rsa / id_rsa.pub ] 파일을 생성했다고 해보자.
   - 다른 PC에서 SSH Public Key를 이용해서 ssh 접속을 하고자 한다면 어떻게 할까?!

   - Key 파일을 생성한 PC 에서 인증을 위해 사용할 Public Key를 등록해야 한다.
   - [ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys ]
   - cp가 아니고 뒤에 첨부하는 식으로 처리한 이유는, 여러개의 Public Key를 등록하는 경우도 있기 때문이다.

   - 참고로 각 파일에 필요한 권한은 다음과 같다.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub 
chmod 644 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/known_hosts


4. 두 대의 PC에서 개발

   - 개발 PC 한 대에서 Key 파일을 하나 생성한 후 Git Server에 등록을 했다고 해보자.
   - 만약 노트북을 한 대 받아서 그곳에서도 개발을 해야한다면 어떻게 해야할까?

   - 가장 손 쉬운 방법은 노트북에서도 Key 파일을 하나 생성해서 추가로 Git Server에 등록을 하는 것이다.
   - 그런데, 추가 등록하지 않고 기존에 생성한 Key 파일을 재활용할 수 있는 방법은 없을까?

   ① Copy

      - [ ssh-keygen -t rsa ] 명령으로 Key 파일을 생성하면,
        [ ~/.ssh/ ] 디렉토리 밑에 id_rsa, id_rsa.pub 파일이 생성된다.
      - 유저에게 필요한 파일은 [ id_rsa ]이고, 서버에 등록을 할 것은 [ id_rsa.pub ] 파일이다.

      - 그런데 이 유저가 다른 PC에서 서버에 접근을 하려고 하는 순간 고민이 생긴다.
      - 전에 사용하던 PC에서는 편하게 Public Key로 인증을 했는데, 이 PC에서는 인증이 안되는 것이다.

      - 사실 정말 간단히 모든 것이 해결된다.
      - 기존 PC에서 생성한 [ id_rsa ] 파일을 [ ~/.ssh/ ] 디렉토리 밑으로 복사해 놓으면 끝이다.

      - 그런데, 이 새로운 PC에 이미 생성해서 사용하고 있는 [ id_rsa ] 파일이 있으면 어떻게 해야할까?

   ② Multi Key

      - Public Key 파일을 관리하기 위해서 별도 설정을 할 수 있다.
      - [ ~/.ssh/config ] 파일에 원하는 내용을 넣으면 되는 것이다.

$ cd ~/.ssh/

$ ls -al
합계 20
drwx------ 2 user2 user2 4096  8월  6 21:22 .
drwxr-xr-x  3 user2 user2 4096  8월  5 01:51 ..
-rw------- 1 user2 user2 1675  8월  5 01:09 id_rsa
-rw-r--r--  1 user2 user2   398  8월  5 01:09 id_rsa.pub
-rw-r--r--  1 user2 user2   222  8월  6 21:22 known_hosts

$ scp chani@127.0.0.1:/home/chani/.ssh/id_rsa ./chani
chani@127.0.0.1's password:
id_rsa                                                        100% 1679     1.6KB/s   00:00   

$ ls -al
합계 24
drwx------ 2 user2 user2 4096  8월  6 21:23 .
drwxr-xr-x  3 user2 user2 4096  8월  5 01:51 ..
-rw------- 1 user2 user2 1679  8월  6 21:23 chani
-rw------- 1 user2 user2 1675  8월  5 01:09 id_rsa
-rw-r--r--  1 user2 user2   398  8월  5 01:09 id_rsa.pub
-rw-r--r--  1 user2 user2   222  8월  6 21:22 known_hosts

   - 'user2'라는 계정에서 'chani'라는 계정으로 Public Key를 이용해서 SSH 접속을 하고 싶은 상황이라고 해보자.
   - 그런데, 'user2'라는 계정에서 이미 Public Key를 생성했기 때문에 id_rsa 파일이 존재하고 있다.
   - 'chani' 계정의 id_rsa 파일을 그대로 복사해올 수가 없어서 'chani'라는 이름으로 바꾸어서 복사를 한 상황이다.


   - 이 상황에서 chani 계정으로 SSH 접속을 시도하면 Public Key를 인식하지 못하고 패스워드를 물어본다.

   - 지금 필요한 것은 [ chani@127.0.0.1 ] 접속을 할 때에 id_rsa 파일이 아니라
     chani 라는 이름으로 복사한 Key 파일을 사용하도록 알려주는 것이다.

   - [ ~/.ssh/config ] 파일을 수정해보자. (없으면 생성하면 된다)

Host 127.0.0.1
        Identityfile ~/.ssh/chani

   - 위와 같이 작성한 후 [ ssh chani@127.0.0.1 ] 실행하면 접속이 될 것이다.

   - 조금 더 체계적으로 config 파일을 작성하면 다음과 같이 할 수도 있다.

Host localhost
        User chani
        Port 22
        Hostname 127.0.0.1
        Identityfile ~/.ssh/chani

   - 조금 불편한 점은 위와 같이 설정한다고 해서 localhost와 127.0.0.1 둘 모두 사용할 수 있는 것은 아니다.

   - 여기에서 중요한 점은 특정 서버에 접속할 때에 사용할 특정 Key 파일을 지정할 수 있다는 것이다.



이번에는 여기까지~



반응형

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

Git (RedHat Enterprise Server 6.3, SourceCode, v1.8.4.1)  (0) 2013.10.22
MS VisualStudio 에서 GIT 지원  (0) 2013.08.31
3D Version Tree  (0) 2013.04.30
[005] Install GIt (in Ubuntu)  (5) 2013.04.25
Empty commit - 내용없는 commit 만들기  (0) 2013.03.31

블로그의 포스트들을 살펴보다가 예전에 스크립만 해놓은 것 중 하나를 발견하게 되었다.
버전 관리 도구의 브랜치를 3D로 보여주는 도구에 대한 포스팅이 바로 그것인데...


   □ Mono Success Story: Plastic
      - http://tirania.org/blog/archive/2006/Sep-05-2.html



3D 예찬론자는 아니지만, 아... 정말 아름답다 !!!

해당 포스팅을 보면 알겠지만, 2006년도 당시에 저 도구는 시중에서 구할 수 있는 것이 아니었다.
그래서 그냥 저런 View를 제공하기 위해서 개발을 하는 곳이 있구나....라는 생각만 할 뿐이었다.

그러다가 또 하나의 아티클을 발견하게 되었다.

   □ LDRA and Codice Software launch Agile development framework
      - http://johndayautomotivelectronics.com/ldra-and-codice-software-launch-agile-development-framework/


어?! 예전에 비해서 상당히 더 세련되어진 모습으로 등장을 했다 !!!
그냥 시험삼아서 개발을 했던 것이 아니라 계속 이어지고 있었던 것이다.


그래서 계속 알아본 결과.... 예쁜 인터페이스로 유명한 plasticscm (http://www.plasticscm.com/) 에서
제공해주고 있는 기능 중 하나라는 것을 확인할 수 있었다.

게임패드를 이용한 3D Version Tree 인터페이스를 한 번 구경해보도록 하자.




"Plastic SCM"이라는 도구가 국내에서는 그다지 지명도가 없지만,
아는 분들은 다 알고 있는 조금은 매니악한 분산형 버전 관리 도구이다.

현재 버전도 4.1 까지 나와있는 나름 오랜 시간동안 예쁨 받고 있는 좋은 버전 관리 도구 이다.

조금 안타까운 점은 돈 많은 회사가 아니라서 그런지 아니면 라인이 좋지 않아서인지
홈페이지에 접속이 시원시원하게 되지를 않는다 !

지금 집에서 접속을 하는데.... 아예 접속이 되지를 않는다.....
너무 예전에 테스트해봐서 기억이 나질 않아, 홈페이지에서 도구 소개글을 찾아보려고 했는데...


뭐 여하튼 이런 것도 있다는 것을 소개 한 번 해봤다~!!

많은 개발자가 다양한 형태로 머지를 하며 개발을 해서 version tree가 복잡할 때
이런 3D로 보여주게 되면 시각적으로 상당히 편리할 수도 있을 것 같다.
반응형

개인적으로 무조건적인 사랑을 주고 싶은 리눅스
그 중에서도 가장 마음에 드는 Ubuntu

Ubuntu에서 Git을 설치해보고자 한다.



1. 패키지로 설치하기


Ubuntu가 11.10으로 업데이트가 되면서
아직 개인적으로도 낯설다.

애정을 가지고 적응을 해야겠지...


"우분투 소프트웨어 센터"에서 "git-core"로 검색을 해서
해당 패키지를 설치하면 바로 git을 사용할 수 있다.

가장 편한 방법이다.




2. 소스로 설치하기

 
Git을 소스로 설치하기 전에 필요한 패키지들을 미리 설치하자

$ sudo apt-get install make libcurl4-gnutls-dev libexpat1-dev gettext libz-dev libssl-dev asciidoc xmlto autoconf

 


엄청 빠른 버전업이 이루어지다가
1.8.x 버전대까지 와서야 조금은 천천히 업그레이드가 되고 있다.

[ Tarballs ] 부분을 클릭하면 다운로드 받을 수 있는 리스트를 확인할 수 있다.


여기에서 다운로드 받을 소스의 주소를 구하자.

$ pwd
/srv/install/git

$ wget http://git-core.googlecode.com/files/git-1.8.2.1.tar.gz

$ tar zxvf git-1.8.2.1.tar.gz

$ cd git-1.8.2.1/

 빌드가 어려울 것이라는 편견은 버리자.

$ make configure
$ ./configure --prefix=/usr/local
$ make all doc
$ sudo make install install-doc install-html

설치가 잘 되었는지 확인을 해보기 위해서 버전 확인을 해보자.

$ git --version


GIT 자동완성을 지원하기 위해서는...
http://whatwant.tistory.com/478


우리 모두 Git으로 행복한 형상관리를...
반응형


소스코드의 변경 없이, 즉 아무런 내용 없이 그냥 commit을 하나 만들고 싶을 때에 사용할 수 있는 옵션이 있다. 사실 정말 아무런 쓸모없는 팁이라고 할 수도 있겠지만, 때로는 정말 유용할 수도 있는 팁이다.

$ git commit --allow-empty -m "[empty] this is a empty commit"
[master 4767699] [empty] this is a empty commit


이런 것이 왜 필요할까 싶기도 하겠지만, 무언가 기록을 남기고 싶을 때 사용하면 유용할 수도 있다. 하지만, 그런 용도로 사용하기 위한 tag 기능이 있는데, 왜 이러한 짓을 하나 싶기도 하다.


사실 필자의 경우에는 root commit을 만들 때 정말 유용하게 사용한다.

repository를 이제 막 생성했을 경우에 empty repository에서는 local에도 아무런 branch가 없고 remote에도 아무런 branch가 없는 정말 삭막한... 말 그대로 깡통 저장소 상태이다.

보통은 이때에 root commit을 만들기 위해서
뜬금없이 readme.txt 같은 텍스트 파일 하나 만들어서 "initial commit"이라고 생성을 하곤 한다.

나중에 괜히 지저분하게 다시 쓸데없는 파일을 삭제하는 commit도 생성이 되고.... 좀 마음에 들지 않는 부분이다.

이럴 때에 empty commit을 사용할 수 있으면... 정말 깔끔해질 수 있다 !!!


별 것도 아닌 내용이긴 하지만,
지금도 많은 개발자들을 위해 애쓰고 있는 개발 환경... 인프라 업무 담당자들을 위해서 짧은 팁 하나 남겨본다 ^^

반응형

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

3D Version Tree  (0) 2013.04.30
[005] Install GIt (in Ubuntu)  (5) 2013.04.25
git diff : 단어 단위로 변경 내역 확인하기  (0) 2013.03.16
commit을 누가 얼마나 했나요?  (0) 2013.03.16
git log 출력 형식 꾸미기  (0) 2013.03.10

최근 commit에서 무엇이 변경되었는지 확인하고 싶을 때 간단하게 사용할 수 있는 명령어로 [ git diff ]가 있다.

사실 변경사항을 확인하기 위해서는 전문적인 diff 도구들을 사용하는 것이 좋다.
[ config merge.tool ] 설정을 할 때에 언급되었던 도구들의 UI가 제일 예쁘다.

하지만, GIT의 특성상 가장 편리한 인터페이스가 Cmmand Line Interface이기 때문에
Consol 환경에서 바로 변경 사항을 확인할 수 있는 방법은 잘 알아두는 것이 좋다.


우선 파일 하나를 변경한 commit이 있는 상황을 가정해보자.

 commit : (HEAD^) d664401  commit : (HEAD) d74336a
 abc  abc def


가장 간편하게 사용할 수 있는 변경사항 확인 방법은 [ git diff HEAD^ ] 명령이다.
하지만 옵션을 사용하면 단어 단위로 변경 내역을 확인 할 수도 있다.
 
 git diff HEAD^  git diff HEAD^ --word-diff
 diff --git a/4th.txt b/4th.txt
index 8baef1b..f9686f5 100644
--- a/4th.txt
+++ b/4th.txt
@@ -1 +1 @@
-abc
+abc def
 diff --git a/4th.txt b/4th.txt
index 8baef1b..f9686f5 100644
--- a/4th.txt
+++ b/4th.txt
@@ -1 +1 @@
abc {+def+}


더 재미있는 옵션도 있다.

$ git diff HEAD^ --word-diff=color

diff --git a/4th.txt b/4th.txt
index 8baef1b..f9686f5 100644
--- a/4th.txt
+++ b/4th.txt
@@ -1 +1 @@
abc def

그러면 삭제된 내역이 있는 경우에는 어떻게 나올까?


 commit : (HEAD^) d74336a  commit : (HEAD) 04c25de
 abc def  def ghi

$ git diff HEAD^ --word-diff=color

diff --git a/4th.txt b/4th.txt
index f9686f5..4842857 100644
--- a/4th.txt
+++ b/4th.txt
@@ -1 +1 @@
abcdef ghi

그렇다. 빨간색은 삭제, 녹색은 추가... 색으로 변경 내역을 확인할 수 있게 해준다.


변경 사항이 많을 때엔 큰 소용이 없겠지만,
소스 코드에서 수치만 변경을 했다던지 일부 단어들을 변경한다던지의 작은 부분의 변경이 있을 때엔
라인 단위의 diff 보다는 단어 단위의 diff가 보다 좋은 가독성을 보여줄 것이다.


굳이 색으로 표현하는 것이 아니더라도 [ --word-diff ] 옵션을 사용해보는 것을 추천한다.

우리 모두 즐거운 Gitster가 됩시다~ ^^
반응형

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

[005] Install GIt (in Ubuntu)  (5) 2013.04.25
Empty commit - 내용없는 commit 만들기  (0) 2013.03.31
commit을 누가 얼마나 했나요?  (0) 2013.03.16
git log 출력 형식 꾸미기  (0) 2013.03.10
Git 1.8.1.3 Release  (0) 2013.02.19

정말 간단한 명령어이지만, 재미있기도 하고 때로는 유용하기도 한 내용이라서 소개하고자 한다.

 
Git 홈페이지에서도 찾을 수 없는(혹시 있을수도...!? ^^),
Pro-Git 책에서도 찾을 수 없는(전 못찾았는데....^^) 재미있는 팁이다.

추가)
   http://dogfeet.github.com/articles/2012/git-secrets.html
   여기에서 간단히 "git shortlog -sn" 명령에 대한 소개가 있긴 하다 ^^

이번에 소개할 내용은 GIT repository에서 누가 얼마나 commit을 했는지 확인하고 싶을 때에 사용할 수 있는 명령어다.

$ git shortlog -sn
 12153  Junio C Hamano
  1398  Shawn O. Pearce
  1106  Linus Torvalds
  1067  Jeff King
   729  Johannes Schindelin
   661  Jonathan Nieder
   510  Jakub Narębski
   480  Nguyễn Thái Ngọc Duy
   470  Eric Wong
   360  René Scharfe
...

위 보기는 실제 git repository에서 실행한 결과이다 ^^ (하마노 아저씨의 commit 수가 절대적이넹....)

재미있는 결과이지만, 전체 commit을 대상으로 하기에 불편할 수도 있다.
만약 초기에 활동한 내역을 제외하고 최근 것만을 대상으로 통계를 내고 싶을 때엔....?!

$ git shortlog -sn -20
    13  Junio C Hamano
     2  Kevin Bracey
     2  Matthieu Moy
     1  Antoine Pelisse
     1  Eric Wong
     1  Jan Pešta
 
[ git log ]에서도 종종 사용하는 옵션으로
가장 최근 20개의 commit을 대상으로 하라고 하기 위해서 옵션 "-20"을 뒤에 붙여서 사용할 수도 있다.

당연하지만 "-" 뒤에 숫자는 각자 취향대로...


하지만, 관리자 입장에서 더더욱 필요한 옵션은 날짜로 제한하는 방법이다.

$ git shortlog -sn --since=2013-03-01
    19  Junio C Hamano
     3  Matthieu Moy
     2  Jiang Xin
     2  Kevin Bracey
     1  Andrew Wong
     1  Antoine Pelisse
     1  Eric Wong
     1  Fredrik Gustafsson
     1  Greg Price
     1  Jan Pešta
     1  Peter Krefting
     1  Ralf Thielow
     1  Thomas Rast
     1  Tran Ngoc Quan


지정한 날짜로부터 commit이 얼마나 되는지 결과를 예쁘게 뽑아준다.

개인적으로 통계가 필요해서 이것 저것 알아보다가.... 추리를 통해서 알아낸 팁이다 ^^

개발자들에게는 반갑지 않은 팁일 수도 있으나....
관리자 역할을 하게 되는 상황에서는 어쩔 수 없이.... 양해를 바라며...
 
반응형

+ Recent posts