Git 재활 훈련 12일차 - git tags

놀고 싶은데, 왜 다들 공부하는거야·2025년 1월 23일

Git

목록 보기

12/14

Git tags

git tag는 특정 branch의 특정 시간 때를 가리켜서 하나의 tag를 두는 것이다. 이는 program을 배포할 때 특정 시점을 기준으로 tag를 사용하여 release를 배포하는 것과 같다.

                                                    tag v3.2.1
                                                        |
                                                        v
main: commit1 --> commit2 --> commit3 --> commit4 --> commit5 --> commit6
                                ^           ^
                                |           |
                            tag v3.2.0   tag blue

tag에는 두 가지 종류가 있다.

lightweight tags: 특정 시점의 name, label을 붙이는 것으로 blue와 같이 큰 의미없이 사용하는 것을 의미한다.
annotated tags: 작성자의 이름, 이메일, 날짜, 필요한 데이터, 메시지 등 meta data를 포함하여 tag를 저장하는 것을 의미한다. 주로 release를 위해 사용하며 v3.2.0, v3.2.1과 같은 것들이 있다.

Semantic versioning

git tag로 특정 release를 기록하는데, release에 많이 사용되는 versioning 기술이 ㅂ로 semantic versioning이다. semantic versioning은 크게 어려울 것 없는 하나의 spec이며 규약이다. 이 명세에 따라, release version을 명시하면 된다.

major.minor.patch
  3  .  2  .  0

최초의 version은 보통 1.0.0부터 시작한다. 보통 patch부터 올라가고 minor, major 순으로 업데이트 된다.

patch: 단순한 버그 수정 건이나, 아주 미미한 수정 사항만 있어 사용자가 software를 사용하는데 큰 지장이 없을 때 patch를 수정한다. 1.0.0에서 1.0.1이 된다.
minor: minor는 신기능이 추가되었을 때 사용되고, 하위 호환성은 지켜진다. 새롭게 추가된 게 있지만 이로 인해 사용자가 바꿔야 할 것은 없다. 1.0.2에서 minor가 올라가면 1.1.0이 된다. patch는 0으로 초기화되는 것이다.
major: 기능의 완전한 변경으로 인해서, 하위 호환성을 지원하지 않는 경우 major를 바꾼다. 1.2.12에서 major가 상승하면 2.0.0이 된다. major가 올라가면 minor와 patch가 모두 0으로 초기화된다.

가령 bootstrap의 경우의 tag들을 보도록 하자. https://github.com/twbs/bootstrap/tags

글을 쓴 시점의 경우 v5.3.3까지 나왔는데, v5.3.2와의 차이를 보면 기능의 변화는 없다. 이것이 patch만 올린 이유인 것이다.

git tag 명령어

실습을 위해 react github인 https://github.com/facebook/react에 들어가보도록 하자.

clone하여 tag에 대한 실습을 해보도록 하자.

git clone https://github.com/facebook/react.git
cd ./react

여기서 git tag를 입력해보자.

git tag

0.14.10
1.2.5
15.3.1
15.3.2
16.0.0-beta.1
16.0.0-beta.3
16.0.0-beta.4
16.0.0-beta.5
16.1.0
...
v18.3.1
v19.0.0

가장 최근 버전이 v19.0.0이라는 것을 볼 수 있다.

git tag가 너무 많아서 검색하기 어렵다면 fileter를 걸어서 검색을 할 수 있다.

git tag -l  "*beate*"

-l 뒤에 정규표현식을 통해 검색을 할 수 있다.

v17에 대한 tag들을 검색해보도록 하자.

git tag -l "v17*"

v17.0.0
v17.0.1
v17.0.2

-l 옵션 없이 검색하면 신규 git tag를 만드는 명령어로 오해하므로 반드시 -l로 filtering을 해주도록 한다.

git checkout branch처럼 git checkout을 통해서 특정 tag로 이동할 수 있다. 이렇게 tag를 통해서 이동하게 되면 HEAD가 detached되기 때문에 해당 git tag가 있는 code들로 working directory가 바뀌게 된다.

git checkout v17.0.0 
HEAD is now at 89b610969d Bump versions for 17

이렇게 이동한 tag에서 특정 branch를 만들어 추가적인 동작을 할 수도 있다.

git switch -c BRANCH_FROM_TAG

이렇게 git tag로 특정 commit으로 가서 새로운 branch 생성이 가능하다.

git diff를 통해서 tag끼리의 비교도 가능하다.

git diff v17.0.0 v17.0.1

diff --git a/packages/react-reconciler/src/ReactFiberLane.js b/packages/react-reconciler/src/ReactFiberLane.js
index 3dc89c45a9..027754dd76 100644
--- a/packages/react-reconciler/src/ReactFiberLane.js
+++ b/packages/react-reconciler/src/ReactFiberLane.js
@@ -640,7 +640,13 @@ export function higherLanePriority(
 }
 
 export function createLaneMap<T>(initial: T): LaneMap<T> {
-  return new Array(TotalLanes).fill(initial);
+  // Intentionally pushing one by one.
+  // https://v8.dev/blog/elements-kinds#avoid-creating-holes
+  const laneMap = [];
+  for (let i = 0; i < TotalLanes; i++) {
+    laneMap.push(initial);
+  }
+  return laneMap;
 }
 
 export function markRootUpdated(

ReactFiberLane의 createLaneMap code가 추가된 것 이외에 큰 차이가 없다.

git tag 생성

위에서 git tag는 두 가지 종류가 있다고 했다.

lightweight tags
annotated tags

먼저 lightweight tags를 만들어보도록 하자.

git tag <tagname>

tag가 생성되면 해당 tag는 그 시점에 HEAD가 가리키는 곳을 pointing하는 것이다.

먼저 v17이 포함된 tag들을 찾아보자.

git tag -l "v17*"

v17.0.0
v17.0.1
v17.0.2

v17.0.3이라는 lightweight tag를 만들어보자. 보통의 경우 lightweight tag의 경우 다음과 같이 semantic versioning을 쓰지않고, annotated tags로 사용하여 metadata들을 추가하는데, 테스트를 위해 semantic versioning으로 쓰도록 하자.

먼저 v17.0.2로 가보도록 하자.

git checkout v17.0.2

git tag를 만들기 전에 전과 다른 차이를 나타내는 commit을 하나 가져야한다. README에 다음의 code를 입력하도록 하자.

echo "v17.0.3" >> ./README.md
git add ./README.md
git commit -m "add readme"

완료가 되었다면 git tag를 만들어보자.

git tag v17.0.3

잘 만들어졌는 지, 검색해보도록 하자.

git tag -l "v17*"
v17.0.0
v17.0.1
v17.0.2
v17.0.3

v17.0.3을 볼 수 있다.

이렇게 간단하게 lightweight tag를 만들 수 있는 것을 보았다. 다음으로는 annotated tag를 만들어보도록 하자.

annotated tag를 만드는 방법은 -a만 추가해주면 된다.

git tag -a <tagname>

새로운 file을 만들어놓고 commit을 해보도록 하자.

echo "NEW_FEATURE" >> NEW_FEATURE.md
git add ./NEW_FEATURE.md
git commit -m "add NEW_FEATURE"

다음으로 v17.1.0 tag를 만들어보도록 하자.

git tag -a v17.1.0

아래와 같이 text editor가 실행될 것이다.


#
# Write a message for tag:
#   v17.1.0
# Lines starting with '#' will be ignored.

여기에 metadata를 추가하면 된다.

THIS is more stuff about my tag!! its annotated tag:)
#
# Write a message for tag:
#   v17.1.0
# Lines starting with '#' will be ignored.

:wq!로 저장하고 tag가 생성되었는 지 검사해보도록 하자.

git tag -l v17.1.*
v17.1.0

v17.1.0가 제대로 생성된 것을 볼 수 있다. 그럼 v17.1.0 주석에 담긴 추가 정보는 어떻게 볼 수 있을까?? git show를 사용하면 된다.

git show v17.1.0 
tag v17.1.0
Tagger: colt <colt@america.com>
Date:   Wed Jan 22 14:44:36 2025 +0900

THIS is more stuff about my tag!! its annotated tag:)

commit 4ee8d42ad2b7933e15eccc7cc696c9d731fff6df (HEAD, tag: v17.1.0)
Author: colt <colt@america.com>
Date:   Wed Jan 22 14:44:14 2025 +0900

    add NEW_FEATURE

diff --git a/NEW_FEATURE.md b/NEW_FEATURE.md
new file mode 100644
index 0000000000..076065ddbb
--- /dev/null
+++ b/NEW_FEATURE.md
@@ -0,0 +1 @@
+NEW_FEATURE

다음과 같이 metadata들이 나오는 것을 볼 수 있다.

git tag를 할 때는 HEAD를 기준으로 tag를 기록하는데, 특정 commit을 기준으로 만들고 싶을 때가 있을 수 있다.

                   HEAD
                    |
                    v
main: commit1 --> commit2

별다른 명령어를 입력하지 않으면 HEAD를 기준으로 tag가 작성되므로 commit2를 기준으로 만들어진다. 만약 commit1를 기준으로 tag를 만들고 싶다면 다음과 같이 써야한다.

git tag <tagname> <commit>

특정 commit을 기준으로 tag를 만들기 위해서 commit을 선정해보도록 하자.

git log --oneline 
4ee8d42ad2 (HEAD, tag: v17.1.0) add NEW_FEATURE
386ca3534a (tag: v17.0.3) add readme
12adaffef7 (tag: v17.0.2, origin/17.0.2) Remove scheduler sampling profiler shared array buffer (#20840)
b2bbee7ba3 Disable (unstable) scheduler sampling profiler for OSS builds (#20832)
8cc6ff2488 fix: use SharedArrayBuffer only when cross-origin isolation is enabled (#20831)
8e5adfbd7e (tag: v17.0.1, origin/17.0.1) Remove usage of Array#fill (#20071)
89b610969d (tag: v17.0.0, origin/17.0.0-dev) Bump versions for 17
4ead6b5305 Treat <time> tag as a normal HTML tag. (#19951)
1992d97306 Revert "Temporarily disable Profiler commit hooks flag (#19900)" (#19960)
44d39c4d76 Removed skip-error-boundaries modifications from old fork (#19961)
461cd84944 Revert "DevTools: Improve browser extension iframe support (#19854)" (#19959)
cc77be957e Remove unnecessary error overriding in (#19949)
97625272ab Debug tracing tests for CPU bound suspense (#19943)
...

44d39c4d76 해당 commot을 기준으로 tag를 만들어보자.

git tag mytag 44d39c4d76

lightweight tag, annotated tag 모두 다 가능하다. 위의 예제는 lightweight tag로 만들었다.

잘 생성된 것을 볼 수 있다.

git tag -l mytag
mytag

만약, tag를 이미 만들었는데 새로운 commit을 추가해야하는 상황이라면? 또는 이전 commit 기준으로 다시 만들고 싶다면? 이러한 경우에는 git tag 명령어로 tag가 가리키는 commit의 위치를 수정할 수 있다.

git tag <tag-name> <commit-hash> -f

-f를 통해서 강제적으로 tag-name가 가리키는 commit을 commit-hash로 바꿀 수 있다.

단, 해당 명령어는 정말정말 신중히 사용하도록 하자. 거의 사용하지 않는 편이 좋다.

tag를 삭제하는 명령어는 다음과 같다.

git tag -d <tag-name>

우리가 만든 mytag를 삭제해보도록 하자.

git tag -d mytag
Deleted tag 'mytag' (was 44d39c4d76)

pushing tag

git tag를 만들면 local에만 영향이 있고, github에는 올라가지 않는다. github에도 올리고 싶다면 다음의 명령어를 입력해야한다.

git push origin <tag-name>

또는 모든 tag들을 올리고 싶다면 --tags를 붙이면 된다.

git push origin --tags

github에 가서 demo repository를 하나 만들도록 하자.

mkdir demo
cd demo

echo "# demo" >> README.md
git init
git add README.md
git commit -m "commit1"
git branch -M main
git remote add origin https://github.com/colt/demo.git
git push -u origin main

다음으로 tag를 하나 만들어보도록 하자.

git tag mytag

git tag로 검색하면 잘 나오는 것을 볼 수 있다.

git tag
mytag

이제 github에도 push해주도록 하자.

git push origin mytag

mytag라는 git tag가 추가된 것을 볼 수 있을 것이다.

다음은 여러 개의 tag를 github에 올리는 경우이다. 먼저 여러 개의 tag를 만들어보도록 하자.

echo "tag1" >> ./README.md
git add ./README.md
git commit -m "commit2"
git tag mytag2

echo "tag2" >> ./README.md
git add ./README.md
git commit -m "commit3"
git tag mytag3

echo "tag3" >> ./README.md
git add ./README.md
git commit -m "commit4"
git tag mytag4

git tag들이 잘 만들어졌는 지 확인해보도록 하자.

git tag
mytag
mytag2
mytag3
mytag4

다음으로 한 번에 git tag들을 github에 올리도록 하자.

git push origin --tag
...
 * [new tag]         mytag2 -> mytag2
 * [new tag]         mytag3 -> mytag3
 * [new tag]         mytag4 -> mytag4

github에 가서 git tag들을 보면 잘 생성된 것들을 볼 수 있다.

놀고 싶은데, 왜 다들 공부하는거야

R3의 망령

이전 포스트

Git 재활 훈련 11일차 - git interactive rebase

다음 포스트