머가필요해

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


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


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

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


1. build

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

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

 

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

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




2. copy

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

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



3. webrick

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

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

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

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



4. Nginx

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

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

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

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

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

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

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




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

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

이상~

Git에서 계정 別 권한을 주기 위해서 대부분의 경우에 사용하는 SSH,
하지만 push 등을 할 때마다 패스워드를 입력하기가 상당히 귀찮다.

편하게 할 수 있는 방법이 없을까? 당연히 있다!


1. .ssh 확인

   - ~/.ssh/ 경로를 확인하자.

   - ssh 키 파일이 없다.



2. ssh-keygen

   - ssh 키 파일을 생성하자.

   - [ ssh-keygen ] 명령을 실행하고 그냥 다 엔터를 치면 된다.

   - 다시 한 번 [ ~/.ssh/ ] 디렉토리 안의 파일을 확인하면 위 스크린샷과 같이 파일 2개가 생겼다.
   - 확장자를 보면 알겠지만 [ id_rsa.pub ] 파일이 바로 공개키다.



3. authorized_keys

   - 등록된 사람이라면 그냥 바로 접근을 허용하기 위해서는 authorized_keys 파일을 만들어야 한다.

   - 위의 샘플의 경우는 git repository의 owner가 "chani"이고 사용자 역시 "chani"인 경우다.

   - "chani" 계정에 ssh로 접근하는 사용자가 등록된 사용자인지 확인을 하기 위해서는 "authorized_keys"을 참조한다.

   - [ authorized_keys ]가 등록되어 있으면, 위와 같이 패스워드를 묻지 않고 바로 진행이 된다.



   - 그런데, 위와같이 [ authorized_keys ] 파일을 만들어주는 것은 대단히 원시적인 방법이다.


   - 위와 같이 하면 뒷쪽에 있는 타겟에 [ authorized_key ] 파일을 생성한다!
   - 참고!



곧 알아보려고 하는 gitolite를 활용한 Git 계정관리에서도
기본적으로 활용하는 "SSH 공개키" 사용 방법에 대해서 알아보았다.

이 부분은 Git에서만 적용되는 것이 아니라, SSH 환경에서 기본적으로 적용하는 방식이다.

잘 알아두면 리눅스 환경에서 많은 도움이 될 것이다.

회사에서 사용하는 환경에서 VirtualBox의 공유 폴더가 너무 느려서 계속 푸념만 하다가,
오늘 갑자기 필이 꽂혀서 이 문제를 해결하고자 몇 가지 시도를 했다.


회사에서 사용중인 환경은 아래와 같다.

   - Host   : Ubuntu 10.10 64bit
   - Guest : Windows-XP


증상은, 공유 폴더를 설정하고 게스트에서 공유 폴더를 접근하면 반응이 3~10초 정도가 걸렸다.
심지어 파일을 더블클릭을 하기에도 힘들 지경이었다.

VirtualBox가 업그레이드 되면 해결이 될까? 기다리다 지쳐서 셀프로 해결해보고자 했다.


참고로 회사에서는 보안 이슈로 인해서 스크린샷 등을 포스팅할 수가 없어서,
지금 집에서 별도로 캡쳐를 하고 있다. 참고~ ^^



1. 호스트 전용 어댑터

   - VirtualBox는 VMWare와는 달리 네트워크 설정을 NAT로 하였을 때 호스트와 통신이 바로 안된다. 
   - 호스트와 네트워크를 하기 위해서는 별도로 '호스트 전용 어댑터'를 설정해야 한다.

   - 일단, VirtualBox의 전체 '환경 설정'에서 설정을 해줘야 한다.

   - '네트워크' 부분에서 '호스트 전용 네트워크'에 어댑터가 추가되어야 한다.
   - 위 스크린샷의 경우에는 이미 추가가 되어있는데, 회사에서는 아무것도 없어서 왼쪽의 버튼으로 추가를 해줬다.

   - 그리고 나서는, 게스트의 설정으로 들어가면 된다.

   - 물론 또 네트워크 설정 부분을 살펴봐야 한다.

   - "어댑터 1"은 이미 사용하고 있는 네트워크 설정값이 있을 것이고, 우리는 새로 "어댑터 2"를 손댈 것이다.
   - 물론 이미 다른 설정들을 해주신 분들은 "어댑터 3", "어댑터 4"를 사용하시면 된다.

   - '네트워크 어댑터 사용하기'를 체크하고, ''호스트 전용 어댑터'를 설정하고 "확인"을 해주면 된다.


   - 왜 이렇게 '호스트 전용 어댑터' 설정을 통해서 '공유 폴더'의 속도를 얻으려고 하냐면...
   - VirtualBox에서  '공유 폴더'를 지원하는 방식이 "네트워크 공유" 방식이기 때문이다.
   - 혹시 호스트와 게스트 사이의 네트워크 통로를 별도로 또 뚫어주면 보다 원할하지 않을까?라는 발상이었다.

   - 그런데, 정말로 효과가 있었다! 브라보~!!

   - 정말 만족할만큼 속도가 개선이 되었지만, 다른 사람들은 어떻게 되는지 알아보고 싶어서 구글링을 좀 해봤다.



2. host 파일 수정

   - 구글링을 해보니, 예전부터 계속 나오던 이슈였다.
   - https://forums.virtualbox.org/viewtopic.php?f=7&t=4078&sid=d5b34c4b0cf910ccf6145451587e139e&start=30

   - 게스트가 Windows일 경우에 '공유 폴더'의 경로는 "＼＼vboxsvr＼ <share folder>" 일 것이다.
   - "C:＼windows＼system32＼drivers＼etc＼hosts" 파일을 수정해보자.
   - "127.0.0.1 localhost" 부분을 "127.0.0.1 localhost vboxsvr"이라고 수정하자.
   - 그리고 재부팅을 하면 끝~

   - 이렇게 하면 대부분의 경우 속도 개선이 된다고 한다.

   - 하지만, 1번 방법 적용 후라서 그런지 속도 이득을 체감하기는 힘들지만,
   - 이 방법 역시 1번 방법과 발상은 비슷한 것 같다.



오늘은 한동안 속썩이던 느린 공유 폴더를 해결한 날이라서 너무 기쁘다.
탄력받아서 Git이나 Redmine 관련해서 포스팅을 해야하는데, 오늘 퇴근하고 집에 오니 22시30분이 넘어서리....^^
내일을 위해서 오늘은 이만 쿨쿨~

지금까지 remote repository에서의 branch에 대해서 살펴보면서,
remote repository에 branch를 추가하는 것에 대해서 아직도 알아보지를 않았다.


1. remote branch 생성

   - remote repository 內에 branch를 생성해보자.

   - remote repository에 원하는 branch를 만들고 싶다면 원하는 이름으로 push를 해버리면 된다.
   - 위와 같이 궂이 꼭 별도의 branch를 만들어서 push를 할 필요는 없지만,
     예시와 같이 같은 이름의 branch를 만들어서 그 이름으로 push를 통해서 remote branch를 생성하는 것이 편하다.


2. clone

   - remote repository가 제대로 되어있는지 확인하기 위해서 새로 clone을 한 번 해보자.

3. tracking

   - local master branch에서 작업을 한 뒤에 [ git push ]를 하면 알아서 'origin/master'에 들어간다.
   - 이는 서로간에 tracking 관계가 설정되어 있기에 그냥 되는 것이다.

   - remote에 위치하고 있는 'origin/develop' branch를 따르는 branch를 local에 생성을 하고 싶다면,
     [ git checkout --track origin/develop ] 명령을 사용하면 된다.
   - 그러면, local 에서 'develop' 이라는 이름으로 branch를 생성하고, checkout 까지 한다.
   - 더불어, 핵심 포인트인 'develop ~ origin/develop' 사이에 tracking 기능이 설정이 된다.

   - tracking 관계를 확인하기 위해서는 [ git config -l ] 명령을 사용하면 된다. 뒤의 옵션은 "L"이다.
   - 밑 부분의 branch 를 살펴보면 연결관계를 확인할 수 있다.



4. checkout track

   - [ --track ] 옵션으로 생성을 하게 되면 local branch 이름을 remote branch 이름과 똑같이 설정을 한다.

   - 위와 같이 'hotfix'라는 이름으로 'origin/develop'을 tracking 하는 local branch를 생성하였다.



5. delete

   - 만들었으면 지우는 방법을 알아볼 차례다.

   - [ push ] 명령을 이용하여 remote branch를 삭제하면 되는데, branch 이름 앞에 [ : ]를 붙이면 된다.
   - 지금까지의 명령 방법과는 조금 다른 방식이니 주의해야할 것 같다.



tracking 관계에 있게 되면 기본적으로 둘 사이에 밀접한 관계를 맺고 있다는 의미가 된다.
해당 branch에서 작업한 것은 그 관계에 있는 remote branch에 반영을 하겠다라는 의미가 되기 때문이다.

이는 잘 이용하면 상당히 편하게 작업을 할 수 있을 것이다.


아름다운 근로자의 날이다.
근로자 여러분 모두 파이팅~!!!

Remote Repository의 변경 사항이 있을 때마다 fetch 받아서 merge를 하는 것은
왠지 비효율적인 것 같고 불편한 것 같이 느껴진다.

Git이 그런 아이가 아닌데....

물론 이와는 다른 방법이 있다. 편한 방법이...
이에 대해서 하나씩 살펴보자.



1. After merge

   - 앞에서 진행한 내용이후의 상황을 살펴보자.

   - remote의 변경 사항을 fetch 받아서 지금 작업하고 있는 내용에 merge를 한 상황이다.
   - 그런데, [ git status ]를 하면 "Your branch is ahead of 'origin/master' by 2 commits" 라고 보인다.

   - 하나는 local master branch에서 push 하지 않은 commit 이고,
   - 다른 하나는 merge로 인해서 발생한 commit 이다.



2. clean

   - 일단, 다른 것을 확인해보기 위해서 위와 같이 확인을 했다면, 잠시 정리 작업을 진행하자.

   - local에 남아있는 commits을 remote로 밀어 넣자.
   - [ git status ] 실행 결과가 위와 같이 깔끔해야 한다.



3. pull

   - 앞의 포스팅을 따라했다면, "2nd/bare1repo" 를 만들었을 것이다.
   - 만약에 없다면, 그냥 무시~ ^^

   - remote repository에서 소스를 받아온 후, 아무런 작업이 없었다면 (push 안된 commit이 없는 경우)
   - 위와 같이 그냥 소스코드를 업데이트 하곤 끝이다.



4. remote repository update

   - 오늘 살펴볼 내용을 만들기 위해서 별도의 local에서 작업 후 push하여 remote를 업데이트 해보자.

   - 일단은 모두 정리를 했다면, 위 그림과 같다.

   - 작업을 한 다음에 commit을 하나 했다면 위 그림과 같다.

 

   - 파일 하나 수정 후 commit을 하고, 마지막으로 [ git push ]를 해주자.

   - 위 그림과 같이 "A" commit 상태에서 "B" commit 상태로 'master'와 'origin/master' 모두 변경되었다.



5. git pull

   - 이제 원래 작업하던 local로 변경하여보자.

   - "A" commit 상태였지만, 저 위의 작업으로 인해서 'origin/master'의 실제 상태는 "B" commit 이다.

   - 그런데, master branch에서 소스 수정 후 commit을 하게 되면 어떻게 될까?

   - 이제는 [ git pull ]을 해 볼 시간인데... 어떻게 될까?

   - [ git pull ]을 하게 되면 바로 앞의 포스팅과 같이 'merge commit'을 생성하면서 코드를 섞어준다.

   - 그림으로 살펴보면 위와 같다.



결론은, 아래와 같다.


즉, 최신 변경된 내역을 내가 작업하고 있는 것에 반영하기 위해서는 'git pull'을 사용하는 것이 편하다!!!


더불어서, git의 merge는 "3-way merge"라는 방식이다.




헥헥~ 오늘은 내일 '근로자의 날'을 앞두고,
일요일에 진행한 "두산 vs KIA" 경기를 다시보기로 보면서 역전승이라는 드라마에 감동하면서 포스팅하고 있다.
두산 파이팅~!!!