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

Git Branch에 대해서 계속 살펴보자.


1. git checkout -b


 $ git checkout -b hotfix

   - 브랜치를 만들고 새로 만든 브랜치로 작업 영역을 변경하기 위해서는 2단계의 과정을 거쳐야 한다.
      . [ git branch 블라블라 ] + [ git checkout 블라블라 ]

   - 이걸 한 묶음으로 처리하기 위해서는 아래와 같이 하면 된다.
      . [ git checkout -b 블라블라 ]


2. commit


   - 현재 어느 브랜치에서 작업을 하고 있는지 확인을 하고... [ git branch ]
   - 파일을 하나 수정 후 commit을 하자. [ git commit -a -m "블라블라" ]

   - 지금 긴급히 수정할 꺼리가 있어서 hotfix를 한다고 가정을 해보는 것이다.


3. merge


 $ git branch
 $ git checkout master
 $ git merge hotfix

   - 변경 사항을 가지고 올 브랜치로 checkout을 먼저 하고선, [ git checkout master ]
   - 어느 브랜치의 것을 가지고 와서 merge를 할지 명령을 하면 된다. [ git merge hotfix ]

   - 여기서 궁금한 것은 merge를 한 것은 알겠는데, 파일만 합친 것인지...?!


   - merge를 한 이후 [ git log ]를 해보면, 본래 없던 commit이 추가되어 있는 것이 보일 것이다.
   - 즉, 위의 경우는 "hotfix" 브랜치의 마지막 commit을 "master" 브랜치로 복사해버린 것이다.



4. delete


 $ git branch -d hotfix

   - 용도가 없는 branch를 지울 때엔 '-d' 옵션을 이용하면 된다.




브랜치에 대해서 공부를 하려면 꼭 나타나는 '머지 (merge)'다.
일단 가볍게 맛만 보는 정도에서 마무리 짓겠다.


앞으로도 몇 번 더 포스팅하면서 더 알아보도록 하겠다.

반응형

최근(?) 형상관리 도구에서 가장 중요한 기능 중의 하나가 바로 "브랜치 (branch)"이다.

개발 과정에서 '브랜치'를 활용하여 다양한 프로세스를 적용하게 되는데,
상당수의 형상관리 도구에서 '브랜치'를 사용하기 위해서는 많은 비용이 소요되곤 한다.

반면, Git의 특징 또는 장점으로 종종 언급되는 것이 바로 비교적 쉽고, 가볍게 '브랜치'를 사용할 수 있다는 것이다.

그러면, 이제 그 '브랜치'에 대해서 알아보아야 하는데,
많은 참고 자료들을 보면 좀 어렵게 설명이 되어 있어서 그 본질을 꽤뚫어보기가 쉽지는 않다.

하지만, 우리 사랑하는 "Git"에 대해서 알기 위해서는 꼭 넘어가야만 하는 산이기에,
차근차근 하나씩 알아나가보자.


1. branch 만들기, 현황 확인하기


 $ git branch
 $ git branch anotherbr

현재 repository의 branch 현황을 확인 하기 위해서는 [ git branch ]라고만 하면 된다.

repository를 생성하고 사용하게 되면, 기본적으로 git이 만들어주는 branch가 바로 "master"이다.
즉, branch 관련한 아무런 작업을 하지 않았다면, 그냥 'master' 브랜치에서 작업을 하고 있는 것이다.

그리고 위 스크린샷에서 보는 바와 같이, 현재 작업하고 있는 branch를 알려주는 표시는 "*"이다.


그러면, 새로 branch는 어떻게 만들까? [ git branch 블라블라 ]와 같이 하면 된다!

생성한 이후 [ git branch ]를 통해서 현황을 보면 위와 같이 나타날 것이다.



2. 일단 나는 master


 $ git branch

 $ nano ./readme.txt
 $ git add ./readme.txt
 $ git commit -m "modify readme.txt"
 $ git push

repository에 있는 파일 하나를 수정하여 커밋하고, push를 해보자.
위 스크린샷을 보면 현재 어떤 branch에서 작업을 한 것인지 보일 것이다.



3. 나는 지금 어디에?


 $ git branch
 $ git checkout anotherbr

현재 작업하고 있는 branch를 변경하는 명령어는 [ git checkout 블라블라 ]이다.

위 스크린샷에서 보는 바와 같이 변경 후 [ git branch ]를 해보면 "*"가 변경되어 있는 것이 보일 것이다.

더불어서 좀 전에 'master branch'에서 작업한 파일을 확인해 보면... 뭔가 다른 것을 확인할 수 있을 것이다.



4. HEAD

현재 작업하고 있는 branch를 가리키는 포인터의 이름은 "HEAD"이다.

위의 작업들을 한 번 다시 곱씹어보자.


아무런 작업도 하지 않은 현재의 상태를 보면, C까지 작업을 한 상황에서 현재 사용중은 branch는 'master'다.
물론 당연히 'HEAD'는 'master'를 가리키고 있다.


[ git branch anotherbr ]를 이용해서 branch를 새로 만들었을 경우는 위와 같다.
똑같은 곳을 'master'와 'anotherbr'이 가리키고 있지만, 'HEAD'는 여전히 'master'를 가리키고 있다.


파일 수정작업을 하고 commit을 하였다면, 'master'는 추가로 작업한 모습을 새로 가리키고 되고
현재 작업하고 있는 branch를 가리키는 HEAD는 'master'를 가리키고 있다.

좀 전에 만든 'anotherbr' 브랜치는 여전히 좀 전과 같은 곳을 가리키고 있다.


[ git checkout anotherbr ] 명령어를 쳐서 작업 브랜치를 변경하겠다라고 하면,
'HEAD'는 이제 'anotherbr' 브랜치를 가리키게 된다.

직전에 변경한 파일 내역은 'master' 브랜치에서 이루어진 작업이므로 'anotherbr' 브랜치는 모르는 일이다.





오늘은 일단 여기까지 하고,
branch에 대해서 한 동안 계속 알아나가 보도록 하자~!!

반응형

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

Git Branch (브랜치) - Local Ⅲ (Merge Log)  (0) 2012.04.23
Git Branch (브랜치) - Local Ⅱ (Merge, Delete)  (0) 2012.04.15
Pro Git 번역본  (0) 2012.03.22
Remote - remote, fetch, pull  (0) 2012.03.19
업데이트 - git pull, 중간 정리  (0) 2012.03.17

소스 수정을 했는데 그냥 다시 원위치를 시키고 싶을 경우 어떻게 해야할까?

즉, 저장소에서 가져와서 소스를 막 손을 댔는데,
처음 가져온 상태로 되돌리고 싶을 경우를 말하는 것이다.


 $ git checkout -- ./aviParser.py

위 스크린샷을 보고 설명을 해보겠다.

   - "readme.txt" 파일은 수정 후 commit을 하기 위해서 add를 해놓은 staged 상태이다.
   - "aviParser.py" 파일은 내용을 수정만 해놓은 상태이다.
   - 이 때, "aviParser.py" 파일의 수정한 내용을 취소하고 싶을 경우,
   - [git checkout -- ./aviParser.py]라고 하면, 원위치가 된다.


그런데, 스크린샷을 잘 살펴보면 알 수 있겠지만,
git은 친절하게도 우리가 원하는 것을 다 알려주고 있다.

안내 멘트만 잘 확인하면 별도로 매뉴얼이 필요 없을 정도이다.


다만, 이러한 것들을 위해서는 Git 버전이 1.6.1 이상이어야 한다.
오래된 버전을 사용하고 있다면, 당장 업그레이드를 추천한다!!!



앞에서 살펴본 것과 같이 Undo 기능에 대한 cycle 그래프를 그려보면 아래와 같을 것 같다.


반응형

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

Remove file - git rm  (0) 2012.02.12
Git Remote Repository (git init --bare)  (0) 2012.02.11
Undo - Unstaging (등록 취소 - git reset HEAD)  (0) 2012.02.07
Git 도우미 - TortoiseGit (in Windows)  (0) 2012.02.05
One Shot - commit  (2) 2012.01.22

+ Recent posts