머가필요해

Git 계정 관리에 대해서 알아보면서 이미 한 번 SSH Public Key에 대해서 살펴보았었다.
   - http://whatwant.tistory.com/395


이번에는 예전에 살펴보지 못한 부분들에 대해서 알아보고자 한다.


1. Server : ssh daemon 설정

   - 만약 Git Server에서 Public Key로 접속하는 것을 막아버리고 싶으면 어떻게 해야 힐까?
   - [ /etc/ssh/sshd_config ] 파일을 살펴보면 된다.


   - 그 외에도 다양한 설정들을 살펴볼 수 있고, 손 볼 수 있다.


2. Client : RSA vs DSA

   - SSH Public Key 파일을 생성할 때 보통 RSA 타입을 사용했다.
   - [ ssh-keygen ] 명령어를 보면 DSA 타입에 대해서도 나온다.
   - RSA는 무엇이고 DSA는 무엇일까?

   ※ 아래 내용은 위키피디아(http://ko.wikipedia.org/)의 내용을 많이 참고하고 있습니다.

   ① RSA
      - 1977년 로널드 라이베스트, 아디 샤미르, 레오널드 애들먼의 연구에 의해 체계화 된 공개키 암호시스템이다.
      - (Ron Rivest), (Adi Shamir), (Leonard Adleman) 3명 연구원의 이름 앞글자로 RSA 이름이 지어졌다.
      - 1983년에 발명자들이 소속되어 있던 MIT에 의해 미국에 특허로 등록되었고, 2000년 9월 21일에 그 특허가 만료되었다.
      - RSA 암호체계의 안정성은 큰 숫자를 소인수분해하는 것이 어렵다는 것에 기반을 두고 있다.

   ② DSA (Digital Signature Algorithm)
      - RSA와 마찬가지로 비대칭형 암호화 방식이다.
      - ElGamal 알고리즘을 이용하여 NIST(미국립표준기술연구소)에서 개발한 전자 서명방식이다.
      - 나중에 DSS(Digital Signature Standard)로 이름이 변경된다.
      - 보통 웹인증서에서 사용하는 방식이다.

   - 암호화 속도는 비슷하지만, 키 생성은 DSA가 빠르고 검증속도는 RSA가 빠르다.
   - RSA는 원문을 개인키로 암호화 해야 서명이 가능하지만, DSA는 그렇지 않다.
   - DSA는 전자서명 여부에 따라 예/아니오로 간단하게 사용한다.

   - 개인적으로 궁금한 것은 DSA가 RSA 보다 더 좋은 것인지 확인하고 싶었다.
   - 결론적으로는 뭐 그냥 그렇다. 그냥 RSA를 사용하게 하는 것이 무난하다는 판단이다.


3. SSH Public Key 활용하기

   - A 라는 사용자가 [ssh-keygen -t rsa ] 명령으로 [ id_rsa / id_rsa.pub ] 파일을 생성했다고 해보자.
   - 다른 PC에서 SSH Public Key를 이용해서 ssh 접속을 하고자 한다면 어떻게 할까?!

   - Key 파일을 생성한 PC 에서 인증을 위해 사용할 Public Key를 등록해야 한다.
   - [ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys ]
   - cp가 아니고 뒤에 첨부하는 식으로 처리한 이유는, 여러개의 Public Key를 등록하는 경우도 있기 때문이다.

   - 참고로 각 파일에 필요한 권한은 다음과 같다.



4. 두 대의 PC에서 개발

   - 개발 PC 한 대에서 Key 파일을 하나 생성한 후 Git Server에 등록을 했다고 해보자.
   - 만약 노트북을 한 대 받아서 그곳에서도 개발을 해야한다면 어떻게 해야할까?

   - 가장 손 쉬운 방법은 노트북에서도 Key 파일을 하나 생성해서 추가로 Git Server에 등록을 하는 것이다.
   - 그런데, 추가 등록하지 않고 기존에 생성한 Key 파일을 재활용할 수 있는 방법은 없을까?

   ① Copy

      - [ ssh-keygen -t rsa ] 명령으로 Key 파일을 생성하면,
        [ ~/.ssh/ ] 디렉토리 밑에 id_rsa, id_rsa.pub 파일이 생성된다.
      - 유저에게 필요한 파일은 [ id_rsa ]이고, 서버에 등록을 할 것은 [ id_rsa.pub ] 파일이다.

      - 그런데 이 유저가 다른 PC에서 서버에 접근을 하려고 하는 순간 고민이 생긴다.
      - 전에 사용하던 PC에서는 편하게 Public Key로 인증을 했는데, 이 PC에서는 인증이 안되는 것이다.

      - 사실 정말 간단히 모든 것이 해결된다.
      - 기존 PC에서 생성한 [ id_rsa ] 파일을 [ ~/.ssh/ ] 디렉토리 밑으로 복사해 놓으면 끝이다.

      - 그런데, 이 새로운 PC에 이미 생성해서 사용하고 있는 [ id_rsa ] 파일이 있으면 어떻게 해야할까?

   ② Multi Key

      - Public Key 파일을 관리하기 위해서 별도 설정을 할 수 있다.
      - [ ~/.ssh/config ] 파일에 원하는 내용을 넣으면 되는 것이다.


   - 'user2'라는 계정에서 'chani'라는 계정으로 Public Key를 이용해서 SSH 접속을 하고 싶은 상황이라고 해보자.
   - 그런데, 'user2'라는 계정에서 이미 Public Key를 생성했기 때문에 id_rsa 파일이 존재하고 있다.
   - 'chani' 계정의 id_rsa 파일을 그대로 복사해올 수가 없어서 'chani'라는 이름으로 바꾸어서 복사를 한 상황이다.


   - 이 상황에서 chani 계정으로 SSH 접속을 시도하면 Public Key를 인식하지 못하고 패스워드를 물어본다.

   - 지금 필요한 것은 [ chani@127.0.0.1 ] 접속을 할 때에 id_rsa 파일이 아니라
     chani 라는 이름으로 복사한 Key 파일을 사용하도록 알려주는 것이다.

   - [ ~/.ssh/config ] 파일을 수정해보자. (없으면 생성하면 된다)


   - 위와 같이 작성한 후 [ ssh chani@127.0.0.1 ] 실행하면 접속이 될 것이다.

   - 조금 더 체계적으로 config 파일을 작성하면 다음과 같이 할 수도 있다.


   - 조금 불편한 점은 위와 같이 설정한다고 해서 localhost와 127.0.0.1 둘 모두 사용할 수 있는 것은 아니다.

   - 여기에서 중요한 점은 특정 서버에 접속할 때에 사용할 특정 Key 파일을 지정할 수 있다는 것이다.



이번에는 여기까지~

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에 대한 거의 대부분의 내용은 다 나온 것이 아닐까 생각해본다.....^^