오랜만에 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