지금까지 commit과 merge, branch에 대해서 기본적인 사용 방법들을 알아보았습니다. 그런데, 우리가 기본적으로 git과 github(+소스트리)를 사용하는 목적이 '버전' 관리라고 했었습니다. 그럼 결국 이 '버전'을 관리하는 개념에 대해서도 당연히 알아볼 필요가 있겠죠?
프로그램 / 제품이 업그레이드 되거나 업데이트, 패치가 진행될 때 우리는 버전이 명시되는 것을 확인할 수 있습니다. 이 버전 코드나 숫자를 통해 해당 제품의 맥락과 시점을 파악할 수 있게 됩니다.
흔히 [1.0.0] 같은 형태로 버전을 표시하는 것을 많이 보았을 것입니다. 그럼 이 넘버링을 결정하는 기준은 무엇일까요? 사실 버전 명기에 있어서 절대적인 기준이 있는 것은 아니지만 - 대부분 암묵적으로 통용되는 기준은 있습니다.
예를 들어 어떤 프로그램의 버전이 v.11.6.2라고 표현되어 있다고 가정해 보겠습니다. 꽤 오랫동안 업데이트 된 모양이네요. 이렇게 프로그램 버전은 주로 세 자리로 표현되는 것이 일반적입니다.
맨 앞자리, 11로 표시된 부분은 메이저(major) 업데이트를 의미하게 됩니다. 기능 전반이 크게 업데이트되거나, 메인 UI 또는 기능이 전면 개편되는 수준으로 바뀔 때, 이 맨 앞자리가 바뀌게 됩니다.
두 번째 자리, 6으로 표시된 부분은 마이너(minor) 업데이트를 의미합니다. 일부 기능이나 디자인의 작은 변화가 생겼을 때 숫자를 올려줍니다.
마지막 세 번째 자리, 2로 표시된 부분은 메인터넌스(maintenance) 업데이트를 의미합니다. 버그 픽스, 유지보수 작업 등이 발생했을 때 업데이트 해줍니다.
이제 우리가 실습한 브랜치 작업에서 버전을 명기하고 릴리즈를 진행해 보겠습니다. [master] 브랜치 상태에서 [태그] 버튼을 클릭하여 v1.0.0으로 태그 이름을 지정하고 태그 추가를 진행해 보겠습니다.
태깅을 하고 나면, 커밋에 브랜치와 마찬가지로 해당 태그가 표시되는 것을 확인할 수 있습니다.
자, 이제 이 태그 작업을 github 원격 저장소에서도 확인할 수 있어야겠죠? 현재 상태에서는 소스트리에서만 적용된 태그이므로 별도 push 작업을 진행해줘야 합니다. 현재 상태에서 Push를 클릭해 [master] 브랜치 원격 저장소에도 반영되도록 해보겠습니다. 이때, '모든 태그 푸시'를 꼭 체크해 주세요.
이제 github 웹 페이지로 들어가 보면, 1 tag 항목이 업데이트 되어 표시되는 것을 확인할 수 있습니다. 페이지 우측에도 'Release'라는 항목에 1 tag가 추가되어 있네요. 이것을 클릭해 주면 해당 버전을 zip 파일로도 다운로드할 수 있습니다.
'Project Management > Git & Github' 카테고리의 다른 글
| [Chapter 4] 복수의 repository로 협업(1) - fork 2 (0) | 2023.03.27 |
|---|---|
| [Chapter 4] 복수의 repository로 협업(1) - fork 1 (0) | 2023.03.26 |
| [Chapter 3] repository 협업(7) - Pull Request (0) | 2023.03.24 |
| [Chapter 3] repository 협업(6) - 브랜치 병합하기 : 충돌(conflict) (0) | 2023.03.20 |
| [Chapter 3] repository 협업(5) - 브랜치 병합하기 : fast-forward (0) | 2023.03.19 |
