[Git] 10장 배포 관리와 태그

참조

배포(Release)

  • 프로그램을 개발한 후에는 완성된 결과물을 최종 사용자에게 전달해야 합니다.
  • 이때 최종 사용자에게 전달하는 과정을 배포 라고 합니다.
  • 개발을 완료했다고 해서 결과물을 직접 사용자에게 배포할 수 없습니다.
  • 완성된 형태로 결과물을 배포하려면 코드를 정리하는 작업들이 추가로 필요합니다.
  • 개발 단계에서 발생한 테스트 메시지나 불필요한 주석들을 정리합니다.
  • 이러한 정리 작업을 거쳐 코드를 좀 더 깔끔하게 만들 수 있고, 배포도 가능합니다.
  • 더불어 정리 작업은 조금이지만 코드 용량을 줄이는 효과도 있습니다. 즉, 배포는 정리된 최종 결과물 을 만드는 과정입니다.
  • 과거에는 최종 결과물인 소프트웨어를 CD나 USB 등에 담아 고객에게 전달했습니다.
  • 하드웨어 같은 장비들은 ROM 이라는 저장 장치에 저장해서 배포했습니다.
  • 요즘에는 인터넷이 발달하면서 과거의 물리적인 배포 대신 온라인으로 배포합니다.
  • 인터넷이 연결된 서버에서 최종 결과물의 파일을 직접 내여받을 수 있습니다.
  • 온라인 배포는 물리적 생산 비용과 유통 비용이 들지 않고, 빠르게 배포할 수 있습니다.
  • 이렇게 배포 프로세스가 빨라지면서 코드를 안정적으로 유지하고 테스트하는 것이 더 중요해졌습니다.
  • 따라서 개발자는 코드를 안정적인 상태로 유지하면서 쉽게 배포할 수 있는 도구들이 필요해졌습니다.
  • 배포를 잘하려면 코드를 깔끔하게 정리할 수 있는 환경이 필요합니다.
  • 또, 사용자가 파일을 쉽게 내려받을 수 있게 해야 합니다.
  • 이러한 이유로 깃은 코드를 배포하는 데도 많이 사용됩니다.

버전(Version)

  • 세상에 완벽한 것은 없습니다. 소스 코드도 마찬가지입니다.
  • 배포 당시에는 발견하지 못했는데, 이후에 잘못된 동작을 하거나 예외적인 상황이 생겨 처리하지 못하는 동작들이 있을 수 있습니다.
  • 또는 최종 사용자가 추가 기능을 요구할 때도 있습니다. 이 떄는 코드를 수정해야 합니다.
  • 즉, 소스코드는 개발은 완료한 후에도 계속 수정됩니다.
  • 코드를 수정했다면 개발자 또는 최종 사용자가 이를 확인하고 구별할 수 있어야 합니다.
  • 코드에서 이러한 차이를 구별할 수 있게 하는 것이 바로 버전(version) 입니다.
  • 버전은 프로그램을 수정하거나 개선할 때마다 코드를 구분하려고 부여된 식별자를 의미하며, 보통 숫자를 사용합니다.
  • 숫자가 클수록 최근에 수정된 코드입니다. 버전업(version up) 은 오래된 버전의 프로그램을 최신 버전의 코드로 변경하는 것을 의미합니다.
  • 버전 번호를 부여할 때는 약간의 규칙이 있습니다. 이 규칙은 오래 전부터 업계에서 사용하던 형태로 꼭 사용할 필요는 없지만, 가능하면 따르는 것을 권장합니다.
  • 기본적인 버전은 단일 번호 하나로 구성되어 있습니다.
  • 단일 번호는 프로그램에서 큰 기능을 변경했을 때 바뀝니다.
  • 첫 자리가 0으로 시작하면 아직 초기 개발 중인 제품이라는 의미입니다.
  • 정식 버전은 1부터 시작합니다. 이를 메이저(major) 버전 이라고 합니다.
  • 메이저 번호를 변경하면 하위 버전과 호환성이 낮아질 수도 있습니다.
  • 메이저 버전 다음으로 작은 코드의 변화는 점(.)을 사용하여 구분합니다. 보통 두 자리 또는 세자리 형태의 숫자로 작성합니다.
    • 두 자리 : 1.0
    • 세 자리 : 2.1.4

태그(Tag)

  • 깃에서는 코드 배포를 관리하려고 태그(tag) 기능을 제공합니다.
  • 커밋은 코드 변화를 기록한 것입니다.
  • 그리고 각 커밋은 서로 다른 코드의 상태를 가집니다. 물론 배포를 위해 최종 정리된 커밋도 있습니다.
  • 깃은 정리된 커밋을 배포할 수 있도록 특수한 포인터를 제공하며, 특정 커밋을 가리키는 포인터로 버전을 관리합니다.
  • 그리고 이 포인터를 태그(Tag) 라고 합니다. 즉, 태그는 특정 커밋의 해시 값을 가리키는 꼬리표를 의미합니다.
  • 최종 사용자는 개발자가 부여한 태그를 사용하여 코드 버전을 구별합니다.
  • 또 태그 포인터로 최종 배포판의 커밋을 구별합니다.
  • 태그는 커밋 해시 값을 기준으로 생성됩니다. 그리고 특정 커밋 해시 값을 가리키는 것뿐만 아니라, 꼬리표, 이름과 정보도 포함합니다.
  • 이러한 태그는 추가 정보를 보유하는지 여부에 따라 두 가지로 구분합니다.
    • Annotated : 태그 이름 + 정보 포함
    • Lightweight : 태그 이름만 포함

태그(Tag) 목록

  • 태그를 사용하려면 tag 명령어를 사용합니다.
  • 단독으로 실행할 수도 있고, 옵션을 추가할 수도 있습니다.
  • 옵션은 -l 또는 -list 옵션 을 같이 사용합니다.
$ git tag -l
$ git tag -list

Annotated 태그

  • Annotated 태그 는 깃에서 가장 일반적으로 사용하는 태그 방법입니다.
  • Annotated 는 '주석이 달린' 이라는 뜻입니다.

태그 생성

  • Annotated 태그 를 생성할 때는 커밋의 해시 값뿐 아니라 추가로 생성자 정보 를 같이 넣을 수 있습니다.
  • 예를 들어 이메일, 날짜, 메시지 등 정보입니다.
  • 또 GPS 방식으로 서명도 가능합니다.
  • Annotated 태그를 생성하려면 tag 명령어 뒤에 -a 옵션 을 사용합니다.
$ git tag -a 버전

간단한 메시지

  • Annotated 태그 를 생성할 때는 메시지를 작성해야 합니다.
  • 작성할 태그 정보가 간단하다면 vi 에디터를 사용하지 않고, -m 옵션 으로 대체할 수 있습니다.
  • 커밋 명령어의 -m 옵션과 유사합니다.

소스트리에서 태그 생성

  • 소스트리에서도 태그를 작성할 수 있습니다.

태그는 중복해서 생성할 수 없다

  • 깃에 등록된 태그 이름은 유일해야 합니다.
  • 즉, 태그는 같은 이름으로 중복해서 생성할 수 없습니다.

태그 삭제

  • 태그는 특정 커밋을 가리키는 꼬리표입니다.
  • 실수로 생성할 태그의 커밋을 잘못 지정할 수도 있습니다.
  • 이때는 기존에 생성한 태그를 삭제해야 합니다.
  • 태그는 tag -d 명령어로 삭제할 수 있습니다.
  • 태그 목록에서 삭제된 태그 이름은 이후에 다시 사용할 수 있습니다.
$ git tag -d 태그이름

태그의 상세 정보 확인 : show 명령어

  • Annotated 태그는 커밋의 태그 포인터와 함께 여러 정보를 포함합니다.
  • tag 명령어는 태그의 목록만 출력할 뿐 상세 정보는 표시하지 않습니다.
  • 태그의 상세 정보를 확인하려면 show 명령어를 사용해야 합니다.
$ git show 태그이름

Lightweight 태그

  • Lightweight 태그 는 가장 기본적인 태그입니다.
  • Annotated 태그 와 달리 버전 이름만 있습니다.

체크섬

  • Annotated 태그 에는 커밋 해시 값과 부가적인 정보가 같이 있습니다.
  • 반면 Lightweight 태그 방식은 커밋의 체크섬 만 가지고 있습니다. 또 Annotated 태그에서 사용했던 -a, -m 같은 옵션은 사용할 수 없습니다.
  • Lightweight 태그의 사용법은 간단합니다.
  • 명령어 뒤에 태그 이름만 작성하면 됩니다.
$ git tag 태그이름

태그의 상세 정보 확인

  • 생성된 Lightweight 태그의 상세 정보를 확인해 보겠습니다.
  • Annotated 태그와 달리 별도의 정보가 없는 것 을 확인하실 수 있습니다.

특정 커밋 태그(tag)

  • tag 명령어는 기본적으로 현재 HEAD가 가리키는 커밋을 기준으로 태그를 생성합니다.
  • 현재 HEAD 포인터가 가리키는 커밋이 아닌 특정 커밋을 직접 지정하여 태그를 생성할 수 있습니다.
  • 특정 커밋을 지정하여 커밋을 생성할 때는 마지막 옵션으로 커밋 해시 값을 적습니다.
  • 그러면 tag 명령어 는 지정된 커밋 해시 값을 기준으로 새로운 태그를 생성합니다.
  • 소스트리를 이용하여 특정 커밋 태그 를 생성해 보도록 하겠습니다.
$ git tag -a 태그버전 커밋ID

1. 태그 생성 -> Specified commit 속성 설정

  • 소스트리에서 태그 메뉴를 선택해 주시고, Specified commit 속성 을 선택합니다.

2. 태그 생성할 커밋 선택

  • 여태까지 작업했던 모든 커밋들의 목록들이 나옵니다.
  • 여기서 태그를 생성할 커밋은 선택합니다.

3. 해시 값 저장

  • 2번에서 태그를 선택할 커밋을 정하고 OK 버튼을 클릭하였다면, Specified commit 속성에 자동으로 해당 커밋의 해시 값을 가져온 것을 확인할 수 있습니다.

4. 태그 생성 완료

  • 태그 이름을 설정해주고 태그 생성을 완료합니다.
  • 그럼 사용자가 선택한 커밋의 태그가 생성된 것을 확인하실 수 있습니다.

태그를 사용한 체크아웃

  • 태그는 특정 커밋을 가리키는 포인터입니다.
  • 따라서 태그를 사용하여 특정 커밋으로 체크아웃할 수 있습니다.
  • 체크아웃할 때 브랜치 이름 대신 태그 이름을 입력하면 됩니다.
$ git checkout v1.0.1
Previous HEAD position was d9423e8 Merge branch 'feature'
HEAD is now at 4344e95 3-way 병합 연습 문구 추가

태그 브랜치(tag branch)

  • 태그를 사용하여 체크아웃할 때는 추가 커밋을 작성할 수 없습니다.
  • 추가 커밋 작업이 필요하다면 태그를 기반으로 새 브랜치를 생성합니다.
  • 태그로 생성된 브랜치는 동일한 시작 커밋을 가지며, 새 브랜치에서 원하는 작업을 추가로 할 수 있습니다.
  • 태그로 브랜치를 생성할 때는 커밋의 해시 값 대신 태그 이름을 사용합니다.
  • 태그 이름으로 새 브랜치를 생성하고, 체크아웃까지 동시에 할 수 있습니다.
$ git checkout -b 브랜치 이름 태그이름

태그 공유

  • 로컬 저장소에서 생성한 태그를 원격 저장소로 공유할 수 있습니다.
  • 태그는 불특정 다수에게 최종 소스의 커밋 정보를 알리려고 공유하는 것입니다.
  • 즉, 태그를 공유하는 것은 최종 코드를 배포하는 것과 같습니다.
  • 태그를 사용하여 사용자는 최종 코드를 내려받을 수 있습니다.

원격 저장소 생성

  • 태그 정보를 공유하는 데는 원격 저장소가 필요합니다.
  • 깃허브, 깃랩과 같은 호스팅 서비스를 이용하여 공개 저장소를 생성합니다.

태그 동기화

  • 생성된 원격 저장소로 로컬 저장소의 태그 정보를 공유할 수 있습니다.
  • 태그 정보는 원격 저장소로 자동 전송되지 않으므로 직접 동기화 명령을 수행해야 합니다.
  • 로컬 저장소의 커밋을 원격 저장소로 전송할 때는 push 명령어를 사용합니다.
  • 원격 저장소로 로컬 저장소의 브랜치는 다음과 같이 전송할 수 있습니다.
$ git push 브랜치 이름

전체 태그 동기화

  • 이전에는 태그 1개를 지정하여 원격 저장소로 공유했습니다.
  • 로컬 저장소에는 태그가 여러 개 있습니다.
  • 이 태그를 하나씩 전송하는 것은 불편합니다.
  • 한꺼번에 전송할 수도 있습니다.
  • -tags 옵션을 사용하면 로컬 저장소의 모든 태그를 한꺼번에 원격 저장소로 보낼 수 있습니다.
git push origin -tags

원격 저장소에 로컬과 다른 이름으로 태그 전송

  • push 명령어는 로컬 저장소의 정보를 원격 저장소로 전송합니다.
  • 이때 push 명령어를 사용하여 로컬 저장소의 브랜치를 원격 저장소의 브랜치로 전송할 경우, 다른 이름으로 전송할 수 있습니다.
$ git push origin master:master1
  • 이 예는 로컬 저장소의 master 브랜치를 origin 서버(원격 저장소)의 maste1 브랜치로 등록하는 방법입니다.
  • 이 원리를 응용하여 태그도 동일한 이름이 아닌 다른 이름으로 전송할 수 있습니다.
  • 다음과 같이 콜론(:)을 사용하여 로컬 저장소의 태그 이름과 원격 저장소의 태그 이름을 지정합니다.
$ git push origin 태그이름 : 원격 저장소의 태그 이름

정리

  • 태그는 완성된 코드를 배포하고 관리하는 데 매우 유용합니다.
  • 또 최종 사용자는 태그를 확인하여 어떤 커밋이 완성된 코드인지 쉽게 확인할 수 있습니다.
  • 태그 버전은 패키지들이 배포하고 업데이트하는 기준이기 때문에 PHP의 컴포저나 Node.js의 패키지 등을 개발할 때도 유용하게 사용할 수 있습니다.
  • 실제 현장에서는 코드를 개발하는 과정도 중요하지만, 태그를 사용하여 버전을 유지 관리하는 것도 매우 중요합니다.
  • 아무리 잘 만든 제품이라도 배포와 태그를 잘 관리하지 않는다면 최종 사용자들은 혼돈에 빠지게 됩니다.
728x90

'버전관리' 카테고리의 다른 글

[Git] 12장 고급기능  (0) 2022.06.25
[Git] 11장 서브모듈  (0) 2022.06.25
[Git] 9장 복귀  (0) 2022.06.20
[Git] 8장 병합과 충돌  (0) 2022.06.20
[Git] 7장 임시 처리  (0) 2022.06.20

이 글을 공유하기

댓글

Designed by JB FACTORY