머가필요해

Git 에서 지원하는 기능 중의 한 가지가 바로 hooks 이다.
다른 형상관리 도구 또는 변경관리 도구에서는 trigger 기능이라고도 부른다.

예를 들어 개발자가 Local에서 commit을 한 것을 Remote로 push를 할 때에
어떤 작업을 실행하고 싶은 것이 있을 때 사용할 수 있는 기능이다.

Git의 어떤 행위를 수행 했을 때 특정 작업을 하도록 연결을 하고 싶다면 이 기능을 사용하면 되는 것이다.
 


Redmine에서는 Git을 저장소에 연결할 수 있다.

gitweb에 비해서 기능적으로는 조금 부족할 수도 있지만,
그에 비해서 훨씬 편리하고 예쁜 인터페이스를 자랑한다. 개인적으로 너무나 좋아한다.


그리고 Redmine은 Git의 commit을 작업으로 관리할 수도 있다.

그런데, 이렇게 아름다운 Redmine과 Git의 관계에 몇 가지 문제가 존재한다.
문제일 수도 있고, 그냥 이슈일 수도 있겠다.

1. Redmine과 Git은 같은 위치에 존재해야 한다.
   - Remote repository를 지원하지 않는 것은 정말 아쉽다.
   - mirroring 등의 방법으로 해결할 수는 있지만 문제는 문제다.

2. 대용량 repository 처리 시간에 따른 오류 발생 가능성이 있다.
   - Git 정보를 Web으로 처리하기 위해서 Redmine은 별도 가공을 해야 하는데 이 때 많은 시간이 소요된다.
   - Redmine은 웹으로 처리가 되다보니 지나치게 많은 소요시간이 걸리게 되면 Timeout이 되게 되는 것이다.
   - Apache의 Timeout 시간을 늘리는 것으로 임시조치는 할 수 있지만, 역시 문제는 문제다.

3. Git에 새로운 commit이 push 되었어도 Redmine에 실시간으로 반영되지 않는다.
   - 저장소 탭을 누군가 열어보기 전까지는 Redmine은 Git의 새로운 변경 내역을 알지 못한다.
   - 이 부분은 마땅히 해결할 방법이 없다. 관리자가 정기적으로 저장소 탭을 실행하곤 해야 하는 것이다.
   - 그런데, 이 때 Git의 hooks 기능을 사용하면 된다 !!!



정리해보면,
Redmine에서 형상관리 도구로 Git을 지원을 해주고 있지만 몇 가지 제약사항이 있다.
그 중 한 가지는 Git 저장소의 변경 사항이 실시간으로 Redmine에 반영이 되지 않는다는 것이다.
그래서 Git의 hooks 기능을 이용해 저장소의 변경 사항이 바로 바로 Redmine에 반영이 되도록 해보겠다.


원하는 결과를 얻기 위해서는 고려해야 할 사항들이 있다.
   - 우리가 원하는 기능을 수행할 시기는 Git Repository에 commit이 들어온 다음이다.
   - 우리가 원하는 기능은 Redmine의 저장소 페이지를 자동으로 여는 것이다.
   - Redmine의 저장소 페이지를 열도록 하기 위해서는 페이지를 열 수 있는 권한이 필요하다.


그런데, 이 부분을 처리하기 위해 알아 보던 중 또 하나 새로운 사항을 알게 되었다.

 

Redmine에서 설정 부분의 저장소 부분에 대한 것들을 살펴보자.

아래 적힌 내용은 저자가 테스트해본 결과에 기반한 것이다.
저자가 잘못 알고 있는 부분이 있다면 언제든 알려주기 바란다 !!!!


□ 커밋(commit)된 변경묶음을 자동으로 가져오기
   - Redmine 탭에서 '저장소'를 클릭하여 페이지를 열 때 저장소의 변경 사항을 받아오게 한다.
   - 선택하지 않으면 변경된 사항을 가져오지 않는다. 이런 경우 별도로 cron 작업을 통해서 변경 사항을 적용한다.

□ 저장소 관리에 WS를 사용
   - Redmine 공식적인 설명을 보면, SVN 저장소를 생성하기 위한 스크립트를 설치했을 때 활성화 시켜야 한다고 한다.
   - 그런데, Git refresh를 할 때에도 활성화 되어야 한다. 이유는 아직 모르겠다.

□ API 키
   - 실행 권한을 받기 위해서는 '키 생성'을 하고 이를 사용하면 된다.




자~ 서론이 길었다. 이제 시작해보자.

우리가 원하는 것은 현재 Redmine에 있는 하나의 프로젝트에서 사용하고 있는 Git repository에
새로운 commit이 들어오면 Redmine에게 정보를 리프레쉬 하라고 명령을 보내는 것이다.


1. Redmine 준비하기
   - 위 스크린샷과 같이,
   - [ 관리 → 설정 → 저장소 ] 메뉴에서 설정을 하자.
      ▷ 커밋(commit)된 변경묶음을 자동으로 가져오기 : 활성화
      ▷ 저장소 관리에 WS를 사용 : 활성화
      ▷ API 키 : 키생성


2. 저장소 경로 확인하기
   - 어떤 저장소인지 확인을 하자.

3. Git repository에 hook 설정하기
   - [ post-receive ] hook을 작성하자.


   - [ _apikey ] 값은 위에서 생성한 값을 이용하면 된다.
   - [ _projectid ] 값은 프로젝트의 식별자를 사용한다.



이걸로 끝이다.

그런데, 실제 push 작업을 해보면 무언가 좀 이상한 것이 보일 것이다.


push를 하게 되면 Remote repository 입장에서 commit을 받아들인 후 post-receive 명령까지 수행을 해야 한다.
push 작업이 마무리 되는 순간은 post-receive 스크립트가 모두 완료가 되는 때이다.

그래서, 이렇게 하는 것이 문제가 될 수도 있다. 개발자 입장에서는 commit만 push가 되면 되는데,
(개발자 입장에서) 알지 못할 작업 때문에 push가 완료되는데에 시간이 더 소요되기 때문이다.



단지 어떻게 하는지만 알고 싶은 사람은 여기까지면 충분~!!
조금 더 알고 싶은 사람을 위해 설명을 추가하면...

   - [ http://<redmine url>/sys/fetch_changesets?key=<key값> ]과 같이 사용해도 충분하다.
   - 다만, 위와 같이 사용할 경우 사용하고 있는 redmine 전체에 대해서 refresh 하게 된다.

   - 전체가 아니라 특정 프로젝트만 refresh 하고 싶은 경우 위와 같이 [ &id=<식별자> ]를 붙이면 된다.

   - redmine 가이드를 보면 Git repository 이름을 사용하게 되어있는데, 그렇게 하면 실행이 안되었다.
   - 기능 변경이 있던지, 아니면 뭔가의 오류로 보인다.

   - [ /sys/fetch_changesets ] 주소는 그냥 사용하면 된다.

   - 개발자의 개발 과정에 지장을 주기 싫다면 (push 명령의 완료 시점) 위와 같이 이벤트 드리븐 방식으로 하면 안된다.
   - cron 등의 방법을 사용해서 개발자 부담을 줄여주는 것도 고려해볼만 하다.
   - [ ruby /path_to_redmine/redmine/script/rails runner "Repository.fetch_changesets" -e production > /dev/null 2>&1 & ]


Redmine 공식 가이드는 아래와 같다.

http://www.redmine.org/projects/redmine/wiki/HowTo_setup_automatic_refresh_of_repositories_in_Redmine_on_commit

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

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


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

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

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

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

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


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

이제는 어느정도 안정화가 된 것으로 보이는 GIT이지만,
아직도 종종 업데이트가 올라온다.

실제 업무에 이러한 도구를 도입할 때에 문제 중 하나가 이러한 업데이트이다.
버전 間 차이점이 많으면 사용 버전끼리의 충돌 이슈가 발생할 수 있기 때문이다.

그래서 실무에서는 사용할 버전을 하나 정해놓고 모두 해당 버전을 사용하게 가이드하곤 한다.

그리고 새로운 버전이 올라오면 해당 버전을 반영할 필요가 있을지 먼저 검증을 하고,
필요한 기능이 있다면 예전 버전과의 호환성 검증을 한 이후에 배포를 해야한다.

 

Git 1.8.1.3 Release Notes =========================  Fixes since v1.8.1.2 --------------------   * The attribute mechanism didn't allow limiting attributes to be    applied to only a single directory itself with "path/" like the    exclude mechanism does.  The fix for this in 1.8.1.2 had    performance degradations.   * Command line completion code was inadvertently made incompatible with    older versions of bash by using a newer array notation.   * Scripts to test bash completion was inherently flaky as it was    affected by whatever random things the user may have on $PATH.   * A fix was added to the build procedure to work around buggy    versions of ccache broke the auto-generation of dependencies, which    unfortunately is still relevant because some people use ancient    distros.   * We used to stuff "user@" and then append what we read from    /etc/mailname to come up with a default e-mail ident, but a bug    lost the "user@" part.   * "git am" did not parse datestamp correctly from Hg generated patch,    when it is run in a locale outside C (or en).   * Attempt to "branch --edit-description" an existing branch, while    being on a detached HEAD, errored out.   * "git cherry-pick" did not replay a root commit to an unborn branch.   * We forgot to close the file descriptor reading from "gpg" output,    killing "git log --show-signature" on a long history.   * "git rebase --preserve-merges" lost empty merges in recent versions    of Git.   * Rebasing the history of superproject with change in the submodule    has been broken since v1.7.12.   * A failure to push due to non-ff while on an unborn branch    dereferenced a NULL pointer when showing an error message.  Also contains various documentation fixes.

 

뭔가 많이 고쳐진 것이면 바람직하게 보여야 하는데... 아직도 고칠 것이 많은가~하는 불안감도 살짝 있다는...

오랜만에 git에 대해서 포스팅을 해야하는데,
너무 간만에 하려다보니 감이 돌아오질 않아서 작성하는데 참 오래걸렸다.

(심지어 이미 포스팅한 내용을 중복해서 작성하던 것을 거의 다 작성하고서야 알아서 결국 다 지웠다는 ㅠㅠ)

---[추가]----------------------------------------------------------------------------------------------

어제 후배 한 명이 git tag와 관련하여 물어본 내용이 있는데,
그에 대한 해답을 찾으면서 추가로 알아본 내용에 대해서 여기에 추가를 했습니다~^^ (thanks 열)
-------------------------------------------------------------------------------------------------------

프로젝트를 진행하던 중 배포용 버전을 만들거나 할 때 별도로 표시하고 싶을 때가 있다.
그럴 때 사용하는 것이 바로 Tag 이다.



1. Tag's Type

   - Git에서 제공해주는 Tag 종류는 두 가지가 있다.
      ▷ Lightweight Tag
      ▷ Annotated Tag

   - Lightweight Tag : 특정 commit에 대한 포인터
   - Annotated Tag   : tag를 만든 사람의 이름/이메일, 생성일자, 메세지, 서명 등을 모두 저장

   - 일반적인 경우에는 Lightweight Tag를 사용하는 것을 추천



2. Lightweight Tag

   - 정말 가볍게 편하게 사용할 수 있는 방식이다.
   - 앞에서 말한 바와 같이 특정 commit 시점에 대해서 책갈피를 한 것으로만 여기면 된다.

$ git tag v0.1

   - Lightweight tag는 그냥 'git tag' 뒤에 이름만 붙여주면 된다.
   - 정말 단순히 특정 commit에 대한 포인터이기 때문에 "git show"로  정보 요청을 하면 commit 정보만 보여준다.

   - 그런데, 지금 시점의 commit에 대해서 tagging을 했는데, 이전 commit에 대해서는 어떻게 해야할까?

$ git log --pretty=oneline  $ git tag v0.0.1 51825b

   - 예전 commit을 지칭하기 위해서는 해당 commit의 hash code를 알아야 하니 git log 로 확인을 하자
   - 그리고는 "git tag 태그명" 뒤에 원하는 commit의 hash code를 적어주면 된다.
   - hash code는 다 적어줄 필요 없이 다른 code와 구분될 정도만 적어주면 된다.



3. Annotated Tag

   - 좀 뭔가 있어 보이는, 그러나 좀 무거워 보이는 Annotated Tag에 대해서 살펴보자.

$ git tag -a v0.2 -m "Annotated tag test"

   - 'lightweight tag'와 다른 점은 [ -a ] 옵션을 붙여야 한다는 것이다.
   - 더불어 [ -m ] 옵션을 이용하여 코멘트도 추가할 수 있다.

   - 현재가 아닌 지난 commit에 대해서 tagging을 하는 방법은 앞의 lightweight tag와 같다.
   - 당연히 [ -a ] 옵션은 추가해야 한다.

   - 이 외에 GPG 키를 적용하는 방법 등도 있지만, 이는 별도의 과제로 남겨놓겠다.
     (절대로 귀찮아서..... 지금 졸려서.... 그러는 것...... 맞다.....^^ 지금 코감기 걸려서 체력도 좀...)



4. Tag Push

   - 여기서 궁금증 하나! 이렇게 tagging을 한 것은 서버로 push가 될까?

   - tagging 작업을 했는데, 'git push'를 하면 아무 것도 올라가지 않는다.
   - 으응 ?!

   - tag 내역을 상위 repository로 넣기 위해서는 별도로 선택해서 push를 해줘야 한다.

$ git remote  $ git push origin v0.1

   - 위와 같은 방식으로 지정해서 push를 해주면 쭈우욱 올라간다

   - 그런데, origin 같은 것을 지정하기 귀찮은데... 소스코드는 그냥 [ git push ]를 하면 되는데...

$ git push v0.2

   - 위와 같이 하면 에러가 발생을 한다. 이 부분은 그냥 시키는 대로 해야한다.

   - 더불어 하나씩 push 하기 번거로워서 몽창 넣고 싶으면 [ git push origin --tags ] 와 같이 사용하면 된다.


간만에 Git 관련 포스팅을 하려니 테스팅 환경도 다시 좀 맞춰야 하고,
흐름도 왠지 끊긴 것 같고, 거기에 코감기로 계속 코를 먹느라 배는 부르고....
내일 주말 출근해야하는데 시간은 1시 30분을 넘어가고 있고........으흐흐흐....

요즘 맨날 핑계만 대는 것 같네요... 제 글을 읽으시는 분들 응원 좀 해주시길... ㅠㅠ



---[추가]----------------------------------------------------------------------------------------------
※ 나중에 추가를 하다보니 스크린샷이 위와 이어지지 않을 수 있습니다. 양해 바랍니다.

5. refs

     - tag를 push하게 되면 remote repository에 어떻게 저장이 될까?
     - 일단, tag를 만들어서 remote repository에 넣어보자.

     - 이렇게 서버로 밀어넣은 tag는 어떤 모습으로 저장이 되어있을까?

     - remote repository 밑의 디렉토리 중 [ refs/tags ] 밑에 차곡차곡 예쁘게 정리되어 파일로 저장이 되어있다.
     - [ refs/tags/v0.1 ]과 같은 모습으로 해쉬값을 갖고 있는 텍스트 파일이 해당 tag의 저장된 모습이다.

 

6. tag 삭제

     - 만들었으면 지우고 싶을 때도 있다.
     - local에서 지우는 것은 다음과 같다.

     - 간단하게 local에 저장된 tag를 삭제할 수 있다.
     - 하지만, 이렇게 local에서 삭제를 했다고 하여도 remote repository에 있는 것을 지우는 것은 아니다.

     - 위와 같이 branch와 같은 방식으로 삭제할 수 있다.




7. tag's hierarchy

     - tag를 계층적으로 관리할 수는 없을까?
     - build를 위한 tag와 release를 위한 tag를 구분해서 예쁘게 정리를 하고 싶다면 디렉토리 구조를 이용하면 된다.

     - tag 이름을 위와 같이 디렉토리 구조로 명시해버리면 된다.
     - 생긴 것만 디렉토리 구조가 아니다.

     - remote repository에서 tag가 어떻게 저장되어있는지 확인해보면 실제로 디렉토리 구조로 tag가 위치하고 있다.

     - [ refs/tags/build/king.v0.1/20120810 ]

     - build를 위한 tag이고 king.v0.1 버전 중 20120810 빌드넘버의 빌드라는 의미로 관리할 수 있는 것이다.

     - 구글에서도 이와 같은 방법으로 tagging을 하고 있다. 그렇다고 이 방법이 꼭 모든 상황에서 좋은 것은 아니다!!!



8. usage

     - 지금까지 이것 저것 tag와 관련해서 많이 알아보았지만,
     - 이렇게 설정한 tag를 어떻게 사용하면 되는지에 대해서는 알아보지 않았다.

     - tag를 사용하기 위한 checkout을 하는 방법을 구글링을 해보면 일반적으로 위와 같이 알려준다.
     - [ git checkout 태그명 ]
     - 본래 [ git checkout 브랜치명 ]과 같이 사용하지만, 같은 형식으로 tag도 사용할 수가 있다고 나온다.

     - 그런데, 위 스크린샷을 보면 알겠지만 branch 상황이 묘하게 되어있다.
     - 애초 작업하던 master branch가 아닌 아무 것도 아닌 branch에 위치하고 있는 것이다.

     - 위와 같이 새로 branch를 만들어주면서 그 곳에서 지정한 tag의 snapshot으로 작업을 하면 된다.

     - 예전에는 바로 checkout이 되었지만,
     - 최근 버전의 git에서는 별도의 branch를 만들면서 tag를 사용해야 하는 것으로 보인다.

     - 정확한 사실은 모르겠다. 하지만, 제대로 사용하기 위해서는 바로 위와 같이 별도로 branch를 생성하면 된다.


이 정도면 git에서의 tag에 대한 거의 대부분의 내용은 다 나온 것이 아닐까 생각해본다.....^^

Redmine의 장점 중 하나가 바로 형상관리 도구와의 연계이다.
Git 역시 Redmine과 잘 연동이 된다.

하지만 환경 설정을 좀 해줘야 한다.


1. config/configuration.yml

     - git을 사용하고 싶으면 실행파일의 경로를 알려줘야 한다.

     - 윗 부분은 이메일 셋팅이고, 아랫부분이 형상관리 도구 경로를 명시해주는 부분이다.
     - git을 사용하기 위해서 [ scm_git_command: /usr/local/bin/git ] 부분을 명시해주면 되는 것이다.



2. 전체 설정 - 저장소

     - 위와 같이 설정을 해주면 이제 사용할 수 있다.

     - 관리자 계정 (admin)으로 로그인해서 관리 메뉴를 고르고 저장소 항목을 보면 위와 같은 화면을 볼 수 있다.
     - 설정이 안된 도구들은 사용할 수가 없다는 것을 알 수 있을 것이다.



3. Project 저장소

     - 그러면 이제 실제 프로젝트에서의 설정을 살펴보자.

     - 위와 같이 간편하게 설정할 수 있다.
     - "Main repository"와 "식별자" 부분이 있는 것은 하나의 프로젝트에 복수의 저장소를 사용하는 경우 때문이다.



4. Remote Repository

     - 그런데, Redmine과 Repository는 기본적으로 같은 Local에 있어야지만 된다.
     - 만약 별도의 서버에 존재한다면 mirror repository를 만든다던지 해서 결국 같은 local에 위치시켜야 한다.

     - 일반적으로 Redmine이 있는 서버에 다른 서버에 위치하고 있는 repository를 clone을 한다.
     - 그리고, crontab 등을 이용해서 동기화를 하여 사용하는 형식을 취한다.


     - 위와 같이 하면 된다고 하지만, 실제 위와 같이 운용해보지는 않았다.



5. Authority

     - local에 위치한 repository를 위 스크린샷과 같이 경로만 적어주면 Redmine이 알아서 이해를 해야하는데...
     - 그게 생각처럼 바로 잘 되는 경우가 없다. 그 이유는 바로 권한 !!!

     - 지금 현재 필자가 구동하고 있는 Redmine은 ubuntu 패키지 설치로 apache2로 하고 있다.
     - 그래서 웹서버가 www-data 계정으로 구동되고 있다.
     - 따라서 Redmine에서 저장소를 보기 위해 접근하고 있는 것은 www-data 계정이다.


     - 여기에선 이 글을 보고 계신 분의 설정 상황에 많이 좌우된다.
     - 즉, 여기에 쓰여져 있는 내용을 참조해서 본인의 상황에 맞춰 잘 판단해서 적용해야 한다.

     - 현재 repository는 git 계정으로 gitolite를 활용하여 운용이 되고 있고,
     - 그래서 사용자가 접근하여 사용하는 모든 행위는 git 계정의 권한으로 이루어지고 있다.
     - 그리고 앞에서 설명한 바와 같이 redmine은 apache2의 www-data 계정으로 활동을 한다.

     - 그래서 위와 같이 repository 들의 소유권 중에서 그룹을 www-data로 전부 변경을 해버리자.
     - 기본적으로 그룹에게 읽기 권한은 주어져 있는 상태이기 때문에 redmine에서 저장소 접근이 된다.

     - 그런데, 여기에서 또 하나 고려해야 하는 것이 있다.
     - 지금 현재 상태에서는 접근이 잘 되지만,
     - 사용자가 push를 하게 되면 그 때 생성되거나 수정된 파일의 권한이 바뀌면서 redmine에서 저장소를 못 읽는다.

     - 그렇다면, 그냥 git 계정의 정체를 바꿔버리면 간단히 해결이 된다.
     - 즉, git 계정의 소속 그룹을 그냥 www-data로 바꿔버리는 것이다.

     - 최신 버전은 commit의 흐름도 제일 왼쪽에 visual하게 보여주어서 더더욱 마음에 든다!!!!!



Redmine 사용자 분들에게 많은 도움이 되길 기원하며....