Git Tag를 활용한 시멘틱 버전 관리

회사에서 개발 중인 프로젝트가 이제 실 운영에 들어가면서 버전 관리가 중요하게 되었다.

그래서 Git Tag를 이용하여 버전 관리를 진행하기로 했다

 

 

나무위키 시멘틱 버전 이미지

버전은 시멘틱 버저닝으로 매기기로 했다.

 

시멘틱 버전은 앞에서부터 Major.minor.patch(1.1.1) 형식으로 이루어져 있다.

 

해당 시멘틱 버전을 이용하여, 패치와 마이너, 메이저 업데이트를 구분할 수 있다.

 

나무위키 피셜:

• • 메이저 버전: 하위 호환성을 보장하지 않는 API 변경사항(breaking change)를 하나라도 포함한 버전에 해당한다. 가령 기존 API를 삭제하거나, 완전히 새로운 API로 통합하는 경우 등. 이러한 경우, 메이저 버전을 올려야 한다. 유일한 예외로, 메이저 버전이 0인 동안은 어떤 불안정한 API 변경사항이 발생하더라도 꼭 메이저 버전을 올리지 않아도 된다. 이 시기를 개발 단계라고 하며, 최초의 메이저 버전(1.0.0)을 공개한 이후로는 일반적인 메이저 버전 원칙을 따른다.
  • 마이너 버전: 하위 호환성이 있는 API 변경사항을 의미한다. 가령 기존 기능을 전부 남기고 새로운 기능을 추가하는 경우, 기존 API를 deprecate하는 등의 경우, 신규 버전을 기존 소프트웨어에서 그대로 사용할 수 있으므로 업그레이드를 해도 안전함이 보장된다. 이런 경우 마이너 버전을 올린다.
  • 패치 버전: 단순 버그를 수정하는 경우나 리팩토링 등, 표면상의(public surface) API 변경사항이 없으면서 업그레이드가 권장되는 경우 등이 해당한다.
  • 사전 릴리즈: 각 버전을 정식으로 배포하기 전에 공개되는 버전으로, 일반적인 버전 뒤에 -와 식별자를 붙여 나타낼 수 있다. 가령 1.2.3-alpha.7의 경우 -alpha.7이 사전 릴리즈 번호이다. 공백을 쓸 수 없기 때문에 .으로 각 식별자를 구분하며, 1.1.1-a.12.b.34와 같이 .으로 여러 식별자를 원하는 만큼 연결할 수 있다. 이때 순서는 각각의 식별자를 앞에서부터 순서대로 비교하며, 각각의 식별자는 숫자로 이루어진 경우 일반적인 정수 순서를, 문자열일 경우 일반적인 사전식 순서에 따른다. 가령 1.0.0-pre.3은 1.0.0-pre.0보다 신규 버전이다. 비슷하게 1.0.0-rc.1은 1.0.0-beta.9와 비교했을 때 문자 r이 b보다 크므로 신규 버전이다. 숫자와 문자열이 같은 위치에 있는 경우 항상 문자열이 더 큰 것으로 간주한다. 가령 1.0.0-alpha.2.tp17이 1.0.0-alpha.2.338보다 신규 버전이다.
  • 빌드 번호: 버전 뒤에 + 기호와 함께 붙은 문자열. 가령 1.2.3+sha.8a4c9fd의 경우 +sha.8a4c9fd 부분이, 4.11.4+20251008.0의 경우 +20251008.0 부분이 빌드 번호이다. 단순히 메타데이터를 넣기 위한 용도이기 때문에 버전 선택 등 과정에서 완전히 무시되며, 빌드 번호를 표시하는 것은 선택 사항이다. 이진 실행 파일인 경우 명령어 집합도 이곳에 명시하기도 한다.

   

  https://namu.wiki/w/%EC%8B%9C%EB%A7%A8%ED%8B%B1%20%EB%B2%84%EC%A0%84

 

이 시멘틱 버전을 우리는 깃 특정 커밋의 해쉬값에 달아서 추후 운영 또는 개발에 롤백이나 기능 추가, 관리 등을 수월하게 진행할 수 있도록 했다.

 

실제 git log

 

실제 시멘틱 버저닝과 git Tag를 적용하니 운영 배포 시에 특정 버전으로 운영팀에 배포 파일 전달 및 설치가 깔끔하게 진행이 되는 것을 느꼈다. 

 

 

 

 

언제나 개발보다 오픈과 운영이 어렵다는 것을 크게 느끼고 있는 요즘이다.