'Work Flow'에 대해서 살펴보기 전에,
'Remote Repository'에 존재하는 'branch'와 'Local Repository'에 존재하는 'branch'의 관계에 대해서 알아보겠다.


조금 다른 일반적인(?) 용어로 이야기를 하자면,
서버에서 소스를 가져와서 작업을 하고 있던 중 서버의 내용이 변경이 되어,
이것을 내가 작업하고 있는 곳에 반영을 하고 싶은 경우에 어떻게 할 것인가? 에 대한 설명을 해보고자 한다.


1. branch -a

   - 현재 작업 공간을 한 번 점검해보도록 하겠다.

   - 오늘 진행할 내용을 위해서 잡다한 것 모두 지우고, 정리하고, push하고 해 놓았다.

   - 여기서 확인하고 싶은 것은 기본적인 branch의 내역이다. "origin/master"의 존재 !!



2. commit in master branch

   - local에서 즉, master에서 commit을 하나 해보자.

   - 여기에서 잘 살펴볼 부분은 [ git status ]를 했을 때 나오는 메시지이다.
   - "Your branch is ahead of 'origin/master' by 1 commit."
   - 최근의 git은 정말 안내 메시지가 너무 잘 되어 있다~!!! 짱~!!!


3. commit in origin/master

   - remote repository에 commit을 하나 추가된 상황을 만들고자 한다.

   - 별도의 commit을 만들어 remote에 넣기 위해서 다른 곳에 별도의 local repository를 clone 하자

   - 파일 하나를 수정하고 commit 한 다음에, remote repository로 밀어넣자(push).



4. fetch & merge

   - remote repository의 변경된 내역을 local로 받아오기 위한 작업을 해보자.

   - remote repository의 정보를 얻어오기 위한 명령어는 [ git fetch ]이다.
   - [ git status ]를 해보면 이전과는 또 다른 메시지가 보일 것이다.

   - " Your branch and 'origin/master' have diverged,
        and have 1 and 1 different commit each, respectively. "

   - " diverge " 뜻을 모르는 저같은 분들을 위한 단어의 의미 :

1. (다른 방향으로) 갈라지다   2. 나뉘다, 갈리다   3. (예상・계획 등에서) 벗어나다

   - [ git log ]를 보면, 위의 그림대로 구성되어진 것을 확인할 수 있을 것이다.




별 것 아닌 것으로 보일 수도 있는데,
git을 혼자서가 아니라 팀으로 작업하는 경우라면 의외로 자주 발생하는 상황일 것이다.

Git에서 보여주는 메시지들을 다시 한 번 잘 살펴보고, 흐름을 잘 느끼고 생각하면 많은 것을 배울 수 있을 것이다.



이런 에잇~ 또 12시를 넘겨버렸네.... ㅠㅠ
오늘 자전거 타이어 바꾸려고 편도 15km가 넘는 거리를 달려갔지만 결국 허탕치고 오늘 자전거만 30km가 넘게 타서...
지금 허리아프고 손목아프고, 목 아프고..... 이런 상황에서 12시를 넘겨버리다니... ㅠㅠ
내일 출근해야하는데.... 흑흑.... 어여 잠자야겠다.

직전 포스팅 서두에 '잡다한 정보'를 알려준다고 해놓고는,
branch에서 가장 중요하다고 할 수 있는 conflict 이야기를 해버렸다. ㅋㅋ

이번에는 정말 branch에 대한 정말 잡스러운 이것 저것들에 대해서 포스팅하기로 하겠다.
이번 포스팅으로 branch 이야기를 마무리 지으려고 하는데... 안되면 한 두번 더 하지 뭐~ ^^



1. git branch & checkout

   - hotfix/patch branch 만들고 'hotfix branch'로 checkout을 하자.

 

2. git branch -v

   - 각 branch 別 마지막 commit을 확인하고 싶으면 [ -v ] 옵션을 사용하면 된다.

3. commit in hotfix branch

   - 'hotfix branch'에서 파일 하나를 수정하고 commit 해보자.

4. commit in master branch

   - 'master branch'에서 commit을 하나 해보자.

5. merge

   - 이번에는 드디어 merge 작업을 해보자.

   - merge를 하게 되면 'hotfix branch'에 있던 commit이 'master branch'에 합쳐진다.
   - 위 그림과 위 스크린샷을 잘 살펴보기 바란다.


6. git branch --merged / --no-merged

   - branch와 관련한 잡스런(?) 정보를 보여주는 옵션들이 있다.

 
   - [ git branch --merged ] merge가 이루어진 branch 목록을 보여준다.

   - [ git branch --no-merged ] merge가 행해지지 않은 branch 목록을 보여준다.

   - 어떤 branch를 만들어서 commit이 한 번 이상 이루어졌을 경우,
     별도의 merge를 하지 않으면 위 스크린샷과 같이 그냥 삭제가 이루어지지 않는다.
   - 강제로 지우고 싶으면 [ -D ] 옵션을 사용하라고 알려주고 있다. 

   - 5번 항목의 그림을 보면 알겠지만, 'patch branch'를 삭제하게 되면,
     "3a45533" commit은 붕~뜨게 된다. 그러기에 그냥 삭제하라고 하면 경고를 하게 되는 것이다.

   - 5번 항목의 그림을 다시 한 번 보게되면, "hotfix branch"의 경우,
     기존에 가지고 있던 "7770966" commit은 "master branch"의 흐름에 같이 섞여버렸다. 

 

 

여기까지해서 Local 에서의 branch 에 대해서는 대강 다 살펴본 것 같다.

앞으로는 이러한 Git 에서의 branch 특성을 이용한 Work Flow에 대해서 간단히 알아보고,
그 다음에는 Remote Repository 를 사용하는 환경에서의 branch에 대해서 알아보도록 하겠다.


오늘은 여기까지.... (우와~ 오늘은 자정 안넘겼다~~~!!! 금일 칼퇴근의 힘~!!!)

조금은 잡스러울 수 있는 부분들에 대해서 알아보자.


1. uncommit

   - 'patch branch'를 생성하고, 그냥 'master branch'에서 파일을 수정한 다음에,
   - commit 하지 않고 'patch branch'로 checkout을 하면...
   - 좀 전에 'master branch'에서 수정한 파일의 내용이 어떻게 될까!?

   - 결론은 변경된 내용이 그대로 'patch branch'에서도 유지가 되어 있다.
   - 위 스크린샷에서 보면, checkout을 한 뒤 나오는 메시지를 보면 [ M    readme.txt ]라는 내용이 보일 것이다.

   - 이는 변경된 파일 내용을 유지하지 않을 경우 그 변경된 내역을 저장할 방법이 없기 때문으로 보인다.
   - 파일의 변경된 사항은 commit 단위로만 기억하는 Git이라는 것을 잘 알고 있어야겠다.



2. conflict

   - branch를 만들어서 각각 다른 부분들을 수정을 했다면, merge에 문제가 없으나,
   - 같은 부분을 서로 수정을 했다면 merge에 문제가 발생을 한다.

$ git branch patch  $ nano ./merge.txt  $ git commit -a -m "modify 1st line in master br"

   - 'patch branch'를 만들어 놓고,
   - 'master branch'에서 'merge.txt'라는 파일의 1번째 줄을 수정하고 commit 한다.

$ git checkout patch  $ nano ./merge.txt  $ git commit -a -m "modify 1st line in patch br"

   - 'patch branch'로 checkout을 한 후 'merge.txt' 파일을 수정 후 commit 한다.
   - 'master branch' 때와 마찬가지로 1번째 줄을 수정한 것이다.

$ git checkout master  $ git merge patch  $ git status

   - 'master branch'로 다시 checkout을 한 뒤에 [ git merge patch ]를 해보자.
   - 충돌이 난 것을 볼 수 있을 것이다 (같은 줄을 각자 수정을 했으니...)

   - 충돌이 난 것을 다시 한 번 보기 위해서는 [ git status ]를 해보면 된다.

$ git mergetool

   - 머지 도구를 활용하기 위해서는 [ git mergetool ]이라고 실행하면 된다.
   - 나의 경우에는 'meld'를 사용한다고 설정을 해놓아서 기본 도구로 (meld)가 보인다.

   - 'meld'의 실행화면이다.
   - 왼쪽이 'master branch'의 파일 내용이고, 오른쪽이 'patch branch' 파일의 내용이다.

   - 수정한 내역이 있으면 위와 같은 화면이 나온다.
   - 저장하고 빠져나오자.

   - 'meld'를 빠져나오면 위 스크린샷과 같이 이상한 파일이 하나 생긴다. "merge.txt.orig"
   - 그 내용을 살펴보면 위와 같이 뭐가 어떻게 충돌이 나는지를 보여준다.

   - 뭐 별 문제가 없다면 그냥 삭제하면 된다.

   - 이제는 merge를 할 때에 충돌이 난 부분을 해결을 했으니, commit을 하면 된다.

   - 그런데, 위 스크린샷을 보면 상당히 특이한 것을 확인할 수 있다.
   - commit 하나만 했을 뿐인데, log를 보면 1개가 아닌 2개의 log가 추가된 것을 볼 수 있다.
   - 즉, patch branch에서 작성한 commit이 자동으로 따라 붙어버린 것이다.




여기까지 해서 conflict 해결하는 것까지 살펴보았다.
이제 자야겠다. 일자가 바뀌었다.
눈알이 빡~빡~

Ubuntu 10.04 64bit를 사용하는 Server에서 Redmine을 패키지로 설치하여 사용하는데...

금일 갑작스레 Redmine이 뜨지를 않는 것이다.
웹으로 접속을 하면 아래와 같은 화면만 보여졌다.



Ubuntu에서 패키지로 제공하는 버전은 Redmine 0.9.3 이다.


대체 뭔일인가 싶어서 아파치의 에러메시지를 살펴보니 아래와 같았다.

$ cat /var/log/apache2/error.log

위 에러에 대해서 검색을 해보니 아래와 같은 내용을 확인할 수 있었다.

   - http://serverfault.com/questions/366406/redmine-suddenly-stopped-working-how-to-troubleshoot

물론 위 사이트에서 친절하게도 문제를 해결할 수 있는 방법도 알려주었다.

   - http://www.redmine.org/projects/redmine/repository/revisions/8909/diff/trunk/app/models/setting.rb



정리를 하자면,
Ubuntu에서 보안 문제로 인해서 Ruby를 업데이트를 해버렸는데 이로 인해서 Redmine이 에러를 내뿜는 것이다.

이게 문제가 되는 부분이 바로 저 위 에러메시지에서 알려주는 바와 같이 "setting.rb" 파일이다!
그러므로 즉, 이 파일만 수정을 해주면 해결이 가능하다.

$ sudo nano /usr/share/redmine/app/models/setting.rb

여기까지...

또 다시 간만에 작성하는 Git 이야기...^^

branch의 경우 설명하는 글들을 읽어도 알기 힘든 부분들이 많다.



오늘 살펴보고자 하는 것은 지난 번 포스팅한 내용 중,
merge를 하게 되면 마지막 commit을 한 내용을 그대로 가져온다고 했었다는 내용에 대해서다.


Git의 branch를 그냥 막 사용한다면 모르겠지만,
하나 하나 그 내용을 분석이 필요하다고 하면 아래 내용을 잘 따라와보면 도움이 될 것이다.



1. 준비

   - 지금 branch를 활용한 작업을 하기 전에 준비를 하자.

$ git branch -a

   - [ git branch -a ] 명령을 통해 모든 branch 상태에 대해서 알아보자.
   - [ * ] 표시가 되어있는 branch가 지금 현재 작업을 하고 있는 branch이다.


2. branch & commit

   - branch를 하나 만들고, 'master branch'에서 commit을 하나 해보자. 

$ git branch patch1  $ nano ./readme.txt  $ git commit -a -m "nano readme.txt in master br"

   - "A" 시점에서 'patch1 branch'를 생성을 하고,
   - 'master branch'에서 파일 수정 후 commit을 해서 "B" 시점으로 갔다.
   - 그래서 'master branch'는 지금 현재 "B" 위치에 있는 것이다.


3. checkout & commit

   - 작업하고 있는 branch를 바꿔보자.

$ git checkout patch1

   - [ git checkout patch1 ]을 통해 작업하고 있는 branch를 변경했다.

$ nano ./readme1.txt  $ git commit -a -m "nano readme1.txt in patch1 br"

   - 'readme1.txt' 파일을 수정 후 commit 하자.

   - commit을 추가로 한 번 더 해보자.

$ nano ./readme1.txt  $ git commit -a -m "1 more, nano readme1.txt in patch1 br"

   - 'patch1 branch'에서 commit 2건을 추가한 것이다.



4. checkout & merge

   - 각 branch 別 상황을 좀 살펴보자.

$ git branch -a  $ git log -2  $ git checkout master  $ git log -2

   - 'patch1 branch'의 log들과 'master branch'의 log들을 잘 살펴보기 바란다.

   - 이제 merge를 실행해 보자.

$ git merge patch1  $ git log -4

   - 위 그림과 스크린샷을 잘 봐야 한다!!! 많은 것들이 녹아 있다.

   - "E" 지점(commit)은 별도로 만든 것이 아니라 'merge'로 만들어진 것이다.
   - 그래서 log를 보면 "Merge branch 'patch1'"이 보일 것이다.

   - 그런데, 또 하나 특이한 것은 'patch1'에서 이루어진 commit까지 모두 따라왔다.
   - 그러면, 'patch1 branch'를 지워버리면 어떻게 될까?

$ git branch -d patch1

   - 'patch1 branch'를 그냥 지워버리면 어떻게 될까?!
   - 위에서 보는 바와 같이 그냥 'branch'만 지워지고 변화는 없다.


   - branch를 지운다고 하여도 그 branch에서 작업을 했던 commit들은 지워지지 않는다는 말 같은데...
   - merge가 되었다면 의미가 있지만, merge가 없는 상태에서 branch를 지웠다면...
   - 의미 없는 commit들이 그냥 살아있다는 말이 되는데...
   - 이 부분에 대해서는 꼭 한 번 깊이있게 살펴볼 예정이다. 개인적으로 관심있는 부분이라서....^^



여하튼, 이번 포스팅에서 확인을 한 것은,
branch에서 만든 commit들이 merge 후에도 계속 따라온다는 것이다.

commit 하나 하나에 더욱 더 신경을 써야 한다는 결론이 나온다.

리눅스를 일반 데스크탑처럼, 워크스테이션으로 사용하더라도,
왠지 리눅스를 사용한다고 하면 Server라는 이미지를 버리기가 힘들다.

그리고 리눅스를 사용하다보면 종종 서버의 역할을 사용하게 되기도 한다.



뭐, 서론이 길었고... 리눅스를 사용하다보면 종종 내 리눅스의 상태를 모니터링하고 싶다는 욕구가 든다.
또 왠지 모니터링 화면을 보면 대단히 있어보이기도 하고....^^

그런데, 서버 어드민에 대한 학습을 하였거나 리눅스에 대해서 그 내부를 공부를 했거나 하였다면 모르겠지만,
그렇지 않다면, 모니터링 도구를 설치하는 것부터 많은 벽에 부딪치게 된다.



그런데, Ubuntu에서 재미있고, 편하게 사용할 수 있는 도구를 제공해주고 있다!
그 이름은 바로 "Munin" !!!

공식 사이트
   - http://munin-monitoring.org/

 Ubuntu의 Munin 소개
   - https://help.ubuntu.com/11.10/serverguide/C/munin.html



1. Install

   - 모니터링 도구로 Munin을 사용하는 이유는 바로 Ubuntu에서 패키지로 제공을 해주기 때문이다!!!

$ sudo apt-get install munin munin-node

   - Munin은 두 가지로 구성되어 있다. Server 역할의 munin과 Client의 minin-node
   - Server의 역할은 munin-node로부터 정보를 얻어와서 웹페이지로 뿌려주는 것이다.

   - Client의 역할을 하는 munin-node는 클라이언트라고 보기보다는 이름 그대로 node라고 해야할 것 같다.
   - 모니터링을 하려는 대상에 심어놓는 모듈이라고 생각하면 될 것 같다.

   - 지금은 하나의 PC에 대해서 모니터링을 하면서 그곳에서 바로 웹으로 결과를 보여줄 것이다.
   - 그래서 하나의 PC에서 munin, munin-node 두가지를 모두 다 설치해버렸다.


2. munin

   - Server의 역할을 하는 munin의 환경 설정을 해보자.

$ sudo nano /etc/munin/munin.conf

[localhost.localdomain]       address 127.0.0.1       use_node_name yes

   - 지금은 자신이 설치된 PC의 것만 모니터링을 할 것이기 때문에 초기값을 그대로 사용해도 된다.

   - 즉, 여기서 설정하는 것은 어떤 node들을 모니터링할 것인가를 적어주는 부분이다.


3. munin-node

   - 여기에서 설정할 것은 누구한테 자신의 정보를 줄 것인지를 알려주어야 한다.

$ sudo nano /etc/munin/munin-node.conf

allow ^127\.0\.0\.1$

   - node에서 Server로 정보를 보내주는 것이 아니라,
     Server가 정보를 내놓으라고 하면 node가 허용한 IP에 대해서만 응답을 하는 방식으로 이해하면 된다.

   - munin과 마찬가지로 기본값으로 그냥 사용하면 된다.




여기부터가 조금 생각을 해야하는 부분인데,
기본적으로 Munin은 Apache2 기반으로 운용이 된다.

그런데, 만약 nginx와 같은 다른 웹서버를 이미 사용을 하고 있다면?!
(내 블로그를 좋아하시는 분들이라면, 이미 Redmine을 사용하실 것이고 그러면.... Nginx를 사용할 것이고....
그러면 일반적인 방법으로 적용이 안될 것이고...

아래 부분은 전체를 한 번 다 살펴보고 나서 다시 셋팅하기를 바란다.

시행착오는 제가 미리 할테니,
여러분은 그걸 보고 올바른 길로만 걸어가시기를... ^^

(리눅스에서 설치같은거 하다가 실패하고 삭제하고 하면 왠지 지저분해지는 것 같잖아요 ^^)





4. apache

   - 모니터링 결과를 웹으로 보여주기 위해서 apache 설정을 해주어야 한다.

$ sudo nano /etc/munin/apache.conf

   - 뭐 딱히 수정할 것은 없다.
   - 물론 특정 IP에만 모니터링을 허용한다던지, 다른 무언가를 원한다면 알아서 수정하면 된다 ^^


5. error

   - 일반적인 경우라면 위와 같이 바로 munin을 사용할 수 있겠지만...

$ sudo service munin-node restart  $ sudo service apache2 restart

   - 그런데, '머가필요해' 본인의 경우에는 apache2가 설치되어있지 않아서 서비스가 구동이 안된다.
   - 그러면, 설치하면 되겠지!?

$ sudo apt-get install apache2

   - 그런데 !!!

   - 위를 보면 빨간 글씨로 [fail]이 보인다.
   - 80번 포트를 이미 다른 놈이 사용하고 있어서 구동하지 못하겠다고 앙알거리는 것이다.


6. munin-nginx-ubuntu

   - Munin을 Nginx 환경에서 구동하기 위해서는 조금 귀찮지만 몇 몇 과정을 거쳐야 한다.
   - https://github.com/jnstq/munin-nginx-ubuntu


7. Nginx

   - Munin을 위해서 필요한 사항들이 있는데, 확인을 해보고 없으면 nginx를 다시 컴파일 해야 한다.

$ /opt/nginx/sbin/nginx -V

   - [--with-http_stub_status_module] 옵션이 보인다면 무관하지만, 없다면 Nginx를 다시 컴파일 해야 한다.


   - PCRE Library가 필요하니 다운로드 받자.
   - ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/

 

$ wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.30.tar.gz  $ tar zxvf ./pcre-8.30.tar.gz

   - Nginx를 다시 컴파일 하기 위해서 source를 다운로드 받아야 한다.
   - http://nginx.org/en/

$ wget http://nginx.org/download/nginx-1.1.19.tar.gz  $ tar zxvf ./nginx-1.1.19.tar.gz

   - 이제 Recompiling을 진행하여보자.

$ cd ./nginx-1.1.19/  $ /opt/nginx/sbin/nginx -V  $ ./configure --prefix=/opt/nginx --with-http_ssl_module --with-cc-opt=-Wno-error --add-module=/srv/install/redmine/passenger/passenger-3.0.11/ext/nginx --with-pcre=../pcre-8.30/ --with-http_stub_status_module  $ make  $ sudo make install

   - ./configure 뒤의 옵션을 참조하기 위해서 [/opt/nginx/sbin/nginx -V]를 확인했다.
   - 그대로 복사해서 사용하고 뒤에 2가지만 추가하면 된다.
   - [ --with-pcre=../pcre-8.30/ --with-http_stub_status_module ]

   - 잘 설치되었는지 확인해보려면 nginx를 재시작하고 서비스 되고 있던 redmine이 잘 보이면 OK

$ sudo /etc/init.d/nginx restart

   -그런데, 내가 잘 이해하지 못한 것이 있는지, 이렇게 restart를 해도 정말 restart가 안되는 것으로 보이기도...
   - process 추적을 해보던지 분석을 해야하지만, 귀찮아서 일단 스탑! ^^

   - nginx의 환경 파일을 다시 한 번 손 보자.

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

server {         listen  8000;         server_name localhost:8000;         location / {             root /var/cache/munin/www;         }     }

   - 8000 번 포트를 사용하기 위해 위와 같은 내용을 추가한다.

$ sudo /etc/init.d/nginx restart

   - 위와 같이 재시작을 하면 되어야 하는데...
   - 뭔가 안된다. 그럴 때엔 확실히 검증하기 위해서.... 재시작!!!... Ubuntu 를 통채로 재시작~!!!

   - 잘 된다~!!!
   - [ nginx restart ] 이 놈이 잘 적용이 안되는 것 같다.
   - 우분투의 재시작으로 적용이 가능하니 일단은 패스~

   - 특별히 뭔가를 하지 않아도 알아서 정보를 차근차근 모은다. 그냥 보면 된다 ^^

   - 주어진 데이타들을 분석하는 것은 각자의 몫~!!!




여기까지~^^