[Git] 형상 관리 / 형상 관리 버전 관리

---

목차

버전 관리

개발 단계 지정하기

버전 등록 관련 주요 기능

버전 관리 과정

---

 

---

[버전 관리]

개발자 A, B, C, D…. 가 있다. 공동으로 서로 작성한 내용을 공유하며 작업한다고 했을 때 A가 작성한 파일을 B,C,D가 받아 사용하고 C가 작성한 파일을 F가 받아 작업할 때 A가 변경한 내용을 바로 B, C, D가 전달받아야지 문제가 발생하지 않는다. 만약 전달이 원활하지 않아 누군가는 이전 버전의 파일로 계속 작업을 한다면 잘못된 결과물이 나올 것이다.

이러한 문제를 해결하기 위해서는 요구사항이 서로 뒤엉키지 않도록 내용이 정확하게 개발자들에게 전달되어야 하기 때문에 버전 관리를 해야 한다.

 

 

 

요구 분석 단계에서 생성된 요구 분석 명세서는 3개의 버전 (V1.1, V1.2, V1.3)으로 진화해왔다.

 

 

---

 

 

 

설계 단계의 최종 산출물인 설계 사양서는 요구분석 명세서를 따라 4개의 버전(V1.1, V1.2, V1.3, V1.4)으로 진화해왔다.

 

 

---

 

 

 

 

마찬가지로 코딩의 결과물인 원시 코드도 5개의 버전(V1.1, V1.2, V1.3, V1.4, V1.5)으로 진화해왔다.

 

 

 

ㅊㅊ. 네이버 지식백과 ( 버전 항목 트리 )

 

개정 순서에 따라 번호가 늘어난다.

현재 사용 가능한 버전을 릴리스 버전 (release version)이라고 하는 경우가 있다.

개정의 폭이 큰 경우엔 version을, 같은 버전 내에서의 소폭 개정을 release라 하여 구별하는 것이 보통이다.

버전에 따라 내용과 기능에 차이가 있으므로 이를 명확하게 표시해야 하며 해당 소프트웨어를 효육적으로 관리하기 위한 목적으로도 사용된다.

 

 

 

요구 분석 명세서(v 1.1) + 설계 사양서(v1.2) + 원시코드(v1.1) = 릴리스 1.0

요구 분석 명세서(v 1.2) + 설계 사양서(v1.3) + 원시코드(v1.3) = 릴리스 2.0

요구 분석 명세서(v 1.3) + 설계 사양서(v1.4) + 원시코드(v1.5) = 릴리스 3.0

 

 

처음 제품으로 출시된 것이 릴리스 1.0이다. 릴리스1.0의 구성은 요구 분석 명세서(v 1.1) + 설계 사양서(v1.2) + 원시코드(v1.1) 로 이루어져 있다. 각 단계는 계속해서 버전 업을 시키고 있고 특정 시점에서 또 새로운 릴리스 2.0을 출시하게 된다.

 

 

---

[개발 단계 지정하기]

개발 중에 사용자들에게 배포하여 기능을 검증받을 목적으로 α버전, β버전 등으로

미리 선을 보인 후 기능이 확정되어 개발이 완료되면 버전 1.0(V1.0)으로 내놓는다.

이때 버전 번호는 점으로 구분된 두 개의 숫자로 구성되어 있다. 점 앞의 숫자는 주 번호, 점 뒤의 숫자는 부 번호라고 한다.

소프트웨어 개발이 크게 변화된 경우 주 번호를 변경시키고, 이전 버전에 있던 오류를 수정하는 정도의 기능 변화가 크지 않을 때는 부 번호를 바꾼다.

 

이후 기능을 개선하여 발표할 때 마다 1.1, 1.2...2.0 등으로 버전을 상품에 표시한다.

세 번째 자리수가 숫자를 0으로 지정하여 아직 배포하기엔 불충분한 수준(알파,베타 버전)을 나타낼 수 있다. 또는 간혹 문자로 표기될 수 있다. 이는 테스트용 혹은 개발 용으로만 사용할 수 있음을 나타낸다.

 

개발된 상품의 기능과 내용이 크게 변화된 경우에는 2.0 또는 3.0 등 주번호를 변경시키며, 이전의 제품에 있던 오류를 수정하는 정도로 기능 변화가 크지 않을 때는 1.1 또는 1.2 처럼 부번호를 바꾼다.

 

프로그램 또는 시스템의 버전을 설명하기 위해 첨부하는 문서를 버전 기술문서라고 하고,

소프트웨어의 옛 버전을 고치거나 기능을 추가하여 새로 발표하는 일을 버전업(Version up)이라 한다.

• 0 - 알파 버전 (alpha)
• 1 - 베타 버전 (beta)
• 발매 버전 후보 (release candidate)
• 발매 버전 (final release)

 

(예시}  

• 1.2.0.1 <- 1.2-a1에서 수정\
• 1.2.1.2 <- 1.2-b2에서 수정 (약간 버그 수정하여 베타 버전으로 업그레이드)
• 1.2.2.3 <- 1.2-rc3 (발매 버전 후보)
• 1.2.3.0 <- 1.2-r (상업용 배포판)
• 1.2.3.5 <- 1.2-r5 (많은 버그를 수정한 상업용 배포판)

 

---

[소프트웨어 버전 등록 관련 주요 기능]

저장소 (Repository) : 최신 버전의 파일들과 변경 내역에 대한 정보들이 저장되어 있는 곳

가져오기 (import) : 버전 관리가 되고 있지 않은 아무것도 없는 저장소(Repository)에 처음으로 파일을 복사함

체크아웃 (check-out) : 프로그램을 수정하기 위해 저장소에서 파일을 받아온다.소스 파일과 함께 버전 관리를 위한 파일들도 받아온다

체크인 (check-in) : 체크아웃 한 파일의 수정을 완료한 후 저장소의 파일을 새로운 버전으로 갱신함

커밋 (commit) : 체크인을 수행할 때 이전에 갱신된 내용이 있는 경우에는 충돌(conflict)을 알리고  diff도구를 이용해 수정한 후 갱신을 완료함

동기화 (update) : 저장소에 있는 최신 버전으로 자신의 작업 공간을 동기화함

 

 

---

[소프트웨어 버전 등록 과정]

 

 

 

[Git] 형상 관리 / 소프트웨어 형상 관리 도구

[Git] 형상 관리 / 형상 관리 구성

[Git] 깃허브(GitHub)란?

[Git] Git 설치하기 / Git 설치 / Git 2.38.1 설치

 

 

 

[ 참고자료 ]

 

소프트웨어 버전 작성 - 위키백과, 우리 모두의 백과사전

 

버전 관리

 

---

잘못된 정보는 댓글에 남겨주시면 감사하겠습니다!😊

댓글과 좋아요는 큰 힘이 됩니다!