오랜만에 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
$ 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
$ 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 (1) | 2012.07.25 |
| Gitweb + Apache2 (2) | 2012.07.16 |
