About Git Tag

Articles 2019/08/03 14:42 용비

Git Tag

아래 내용은 Git Book V2를 참고하여 작성했습니다.
Git Tag에 대한 자세한 내용은 Git Book을 참고하세요.

태그는 일반적으로 제품의 Release 계획에 사용됩니다.
제품에 명시되어 있는 버전 정보가 바로 Release에 사용된 태그입니다.
Git Tag Command 사용 방법은 다음과 같습니다.

Tag 조회

이미 만들어진 태그가 있는지 다음과 같이 조회할 수 있습니다.

git tag -l

특정 문자열을 포함하고 있는 Tag를 조회할 경우에는 다음과 같이 조회합니다.

git tag -l "v.1.*"

Tag 추가

Git의 태그에는 Annotated Tag 와 Lightweight Tag 2가지 종류가 있습니다.

Annotated Tag

Annotated Tag는 Git Database에 태그를 만드는 사람의 이름, 이메일, 태그 생성 일자, 태그 메시지 등을 저장합니다. GPG(GNU Private Guard)로 서명할 수도 있습니다.
일반적으로, Annotated Tag를 사용하여 모든 정보를 저장하는 것이 좋습니다.
Annotated Tag는 -a를 추가하여 다음과 같이 사용할 수 있습니다.

git tag -a v1.4 -m "version 1.4 tag"

-m 옵션을 통해서 메시지를 함께 저장할 수 있습니다.

다음과 같이 git show를 이용하여 Tag 정보와 Commit 정보를 모두 확인할 수도 있습니다.

git show v1.4

Lightweight Tag

Lightweight Tag는 Git의 Branch와 비슷합니다.
하지만, Branch와는 다르게 가리키는 지점을 최신 commit 위치로 이동시키지 않습니다.
단순히 특정 commit에 대해 가리키는 포인터 역할을 하며 파일에 commit checksum을 저장하는 것 뿐입니다.
Lightweight Tag는 -a, -s, -m 옵션을 사용하지 않고, 단지 이름만 붙입니다.

git tag v1.4-test

git show를 이용하여 commit 정보를 확인할 수 있습니다.

기존 commit에 대한 Tag 추가

예전에 개발하여 commit한 소스 코드에 대해서도 나중에 tag를 추가할 수 있습니다.
다음과 같은 순서로 기존 commit에 tag를 추가합니다.

  1. commit history 조회

    git log --pretty=oneline
  2. 특정 commit에 tag 추가
    tag 추가 명령의 끝에 checksum을 명시합니다.

    git tag -a v.1.0 checksum -m "added comment"

    checksum은 긴 checksum을 모두 적지 않고 앞자리 일부만 명시합니다.

  3. Tag 확인

    git tag # tag list 조회 git show v.1.0 # tag를 추가한 commit 조회

Tag 공유

git push 명령은 자동으로 tag 정보를 원격 저장소에 전송하지 않습니다.
branch를 공유하는 방법과 동일하게 tag는 별도로 원격 저장소에 push해야 합니다.

다음과 같이 수행할 수 있습니다.

git push {remote name} {tag name} > ex) git push origin test

--tags 옵션을 추가하여 원격 저장소에 없는 모든 tag들을 한 번에 전송할 수 있습니다.

git push origin --tags

향후, 다른 개발자가 원격 저장소에서 해당 프로젝트를 git pull하거나 git clone하는 경우 tag까지 모두 받을 수 있습니다.

Tag Checkout

특정 버전을 명시한 Tag가 붙어 있는 파일만을 checkout하여 확인하고 싶을 경우, 다음과 같이 실행할 수 있습니다.

git checkout v1.2

tag를 git checkout하는 경우, "detached HEAD" 상태가 되어 기존 branch에서 떨어져 나오게 됩니다.
이후 일부 git 작업이 기존 branch와 다르게 동작할 수 있습니다.
따라서, checkout한 상태에서 새로 작성한 commit이 의미가 있게 하기 위해서는 반드시 별도의 branch로 작업하는 것이 좋습니다.

받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/854

Pipeline :
Spinnaker에서 배포를 위한 주요 구조.
Stage로 부르는 sequence of action으로 이루어짐.
Pipeline 내 Stage 사이에 파라미터 전송 가능.
수동으로 pipeline을 시작하거나, Jenkins Job Completing, new Docker image appearing in registry, CRON Schedule, another pipeline stage 등의 이벤트로 인한 자동 pipeline 시작 가능.
Status에 따라 (start/complete/fail) 정해진 대상자들에게 Notification을 발송하도록 (email, SMS, HitChat) pipeline 설정 가능.
Template에서 생성되었는지의 여부와 관계없이, Deck UI에서 시각화할수 있는 실행가능한 pipeline.
Orca에 의해 실행될 수 있다.
Pipeline Template :
Pipeline instance에서 발견되는 pipeline configuration을 제외한 매개변수화된 pipeline.
이 템플릿은 개발자가 여러분이 설정한 패턴을 따르는 pipeline을 생성하도록 도움을 준다.
Pipeline configuration :
Template에서 생성되지 않은 pipeline 설정과 변수 바인딩, 템플릿 참조가 합해진 것과 같다.
Stage :
Spinnaker의 Pipeline에 대한 Automic Building Block(가장 작은 빌딩 블록).
Pipeline이 실행하고 있는 action을 설명함.
Pipeline에 임의의 순서로 stage를 구성할 수 있고, Deploy, Resize, Disable, Manual Judgement(ex. manual approval)등 다양한 Stage를 지원함.
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/853

Application :
여러 개의 Cluster로 이루어짐 (Collection of clusters) + Load Balancer + Firewall.
Spinnaker를 사용하여 배포하고자 하는 서비스, 서비스의 모든 설정, 서비스가 실행되는 인프라를 나타냄.
서비스별 다른 Application을 만들지만 Spinnaker는 시행하지 않는다.
Cluster :  
여러 개의 Server Group으로 구성됨 (Collections of Server Groups).
여러 개의 Server Group을 묶는 논리적인 단위. Kubernetes의 Cluster와는 다름.
단순히 Spinnaker의 Server Group의 집합.
Server Group :
배포가능한 아티팩트(VM Image, Docker Image, Source location)와 인스턴스 수, autoscaling 정책, 메타데이터 등과 같은 기본 설정을 명시한 기본적인 Resource.
(Optionally) Load Balancer와 Firewall과 관련되어 있다.
배포될 때, Server Group은 VM Instance와 Kubernetes Pod와 같이 동작하고 있는 소프트웨어 Instance의 Collection이다.
Load Balancer :
ingress protocol과 port range와 관련 있음.
Server Group에 있는 Instances 사이에서 Traffic에 대하여 Balancing한다.
Firewall :
Network Traffic Access를 정의한다.
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/852