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

 
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이 얼마나 되는지 결과를 예쁘게 뽑아준다.

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

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

오랜만에 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에 넣어보자.


$ git tag -a 'v0.1' -m 'tag 테스트'
$ git push origin --tags

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


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

 

6. tag 삭제

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


$ git tag -d v0.1

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


$ git push origin :tags/v0.1

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




7. tag's hierarchy

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


$ git tag build/king.v0.1/20120810
$ git push origin --tags

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


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

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

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

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



8. usage

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


$ git checkout build/king.v0.1/20120810

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

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


$ git checkout -b 20120810 build/king.v0.1/20120810

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

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

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


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

반응형

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

Git 1.8.1.3 Release  (0) 2013.02.19
Git 명령어 자동 완성 기능 (Source 설치 時)  (0) 2012.08.20
git blame (-e 옵션)  (0) 2012.07.29
git man  (0) 2012.07.25
Gitweb + Apache2  (2) 2012.07.16

+ Recent posts