위키원
"버전관리"의 두 판 사이의 차이
잔글 (→특징) |
|||
| (사용자 3명의 중간 판 4개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
| − | '''버전관리'''(Version Control, Revision Control)는 [[정보]] | + | '''버전관리'''<!--버전 관리-->(Version Control, Revision Control)는 [[정보]] 및 [[통신]] 프로그램의 소스 코드, 문서, 그래픽 및 관련 파일들을 대단위 소프트웨어로 묶어서 개발 시점으로 표기하여 관리하는 시스템이다. 버전 관리 소프트웨어는 해당 프로그램의 모든 프로그래머 및 개발자들이 프로그램을 개정한 사항들을 추적하는 데 사용되는 [[데이터베이스]]를 제공한다. |
== 개요 == | == 개요 == | ||
| − | 버전관리는 동일한 정보에 대한 여러 버전을 관리하는 | + | 버전관리는 동일한 정보에 대한 여러 버전을 관리하는 시스템이다. 공학과 소프트웨어 개발에서 팀 단위로 개발 중인 소스 코드나, 청사진 같은 설계도 등의 디지털 문서를 관리하는 데 사용된다. 그러한 문서의 변경 사항들에 숫자나 문자로 이루어 졌으며, '개정판 번호' 및 '개정판 레벨'이라고도 불리는 버전을 부여해서 구분한다. 버전을 통해서 시간상으로 변경 사항과 그 변경 사항을 작성한 작업자를 추적할 수 있다. 간단한 버전 관리 방법으로는 처음 작성한 코드에 버전 번호 1을 부여한다. 변경 사항이 생기면, 버전 번호를 2로 증가시킨다. 이처럼 추후 변경 사항을 발견 시마다 버전 번호를 1씩 증가시킨다.<ref name="위키백과">〈[https://ko.wikipedia.org/wiki/%EB%B2%84%EC%A0%84_%EA%B4%80%EB%A6%AC 버전관리]〉, 《위키백과》</ref> |
| − | == 사용 방식 | + | == 특징 == |
| + | ;사용 방식 | ||
A가 어떤 파일을 저장소에 추가한다. 추가되었던 파일을 A가 인출한다. 갑돌이가 인출된 파일을 수정한 다음, 저장소에 예치하면서 설명을 붙인다. 다음날 B가 자신의 작업 공간을 동기화한다. 이때 갑돌이가 추가했던 파일이 전달된다. B가 추가된 파일의 수정 기록을 보면서 갑돌이가 처음 추가한 파일과 이후 변경된 파일의 차이를 본다.<ref name="위키백과"/> | A가 어떤 파일을 저장소에 추가한다. 추가되었던 파일을 A가 인출한다. 갑돌이가 인출된 파일을 수정한 다음, 저장소에 예치하면서 설명을 붙인다. 다음날 B가 자신의 작업 공간을 동기화한다. 이때 갑돌이가 추가했던 파일이 전달된다. B가 추가된 파일의 수정 기록을 보면서 갑돌이가 처음 추가한 파일과 이후 변경된 파일의 차이를 본다.<ref name="위키백과"/> | ||
| − | + | ;필요성 | |
| − | ; | ||
거의 대부분의 주요 소프트웨어 개발 프로젝트는 아직도 소프트웨어의 설계도라 할 수 있는 소스 코드 작성이 주요한 부분이 되며 이러한 소스 코드는 기업체 또는 연구소의 핵심 역량이 응축된 핵심 자산이다. 따라서 어떤 형태로든 소스 코드를 백업하여 분실의 위험에서 보호하고 개정 전후 내용을 파악하여 추후 발생할지도 모를 오류 수정에 대비하는 절차가 필요하다. 버전 관리 소프트웨어는 조직의 핵심 자산인 소스 코드의 개정과 백업 절차를 자동화하여 오류 수정 과정을 도와줄 수 있는 시스템으로 이미 다수의 국제 협력 개방 소프트웨어 개발 실무에서도 널리 사용되고 있다. 다음은 버전 관리 시스템을 사용하는 원인을 정리한 것이다. 무언가 잘못되었을 때 복구를 돕기 위하여 또는, 프로젝트 진행 중 과거의 어떤 시점으로 돌아갈 수 있게 하려고 사용된다. 여러 사람이 같은 프로젝트에 참여할 경우, 각자가 수정한 부분을 팀원 전체가 동기화하는 과정을 자동화하기 위하여, 소스 코드의 변경 사항을 추적하기 위하여, 소스 코드에서 누가 수정했는지 추적하기 위하여 사용되며, 대규모 수정 작업을 더욱 안전하게 진행하기 위하거나, 가지치기로 프로젝트에 영향을 최소화하면서 새로운 부분을 개발하기 위하여, 접붙이기로 검증이 끝난 후 새로이 개발된 부분을 본류에 합치기 위하여, 많은 오픈 소스 프로젝트에서 어떠한 형태로든 버전 관리를 사용하고 있음으로, 코드의 특정 부분이 왜 그렇게 쓰였는지 의미를 추적하기 위하여 사용한다.<ref name="위키백과"/> | 거의 대부분의 주요 소프트웨어 개발 프로젝트는 아직도 소프트웨어의 설계도라 할 수 있는 소스 코드 작성이 주요한 부분이 되며 이러한 소스 코드는 기업체 또는 연구소의 핵심 역량이 응축된 핵심 자산이다. 따라서 어떤 형태로든 소스 코드를 백업하여 분실의 위험에서 보호하고 개정 전후 내용을 파악하여 추후 발생할지도 모를 오류 수정에 대비하는 절차가 필요하다. 버전 관리 소프트웨어는 조직의 핵심 자산인 소스 코드의 개정과 백업 절차를 자동화하여 오류 수정 과정을 도와줄 수 있는 시스템으로 이미 다수의 국제 협력 개방 소프트웨어 개발 실무에서도 널리 사용되고 있다. 다음은 버전 관리 시스템을 사용하는 원인을 정리한 것이다. 무언가 잘못되었을 때 복구를 돕기 위하여 또는, 프로젝트 진행 중 과거의 어떤 시점으로 돌아갈 수 있게 하려고 사용된다. 여러 사람이 같은 프로젝트에 참여할 경우, 각자가 수정한 부분을 팀원 전체가 동기화하는 과정을 자동화하기 위하여, 소스 코드의 변경 사항을 추적하기 위하여, 소스 코드에서 누가 수정했는지 추적하기 위하여 사용되며, 대규모 수정 작업을 더욱 안전하게 진행하기 위하거나, 가지치기로 프로젝트에 영향을 최소화하면서 새로운 부분을 개발하기 위하여, 접붙이기로 검증이 끝난 후 새로이 개발된 부분을 본류에 합치기 위하여, 많은 오픈 소스 프로젝트에서 어떠한 형태로든 버전 관리를 사용하고 있음으로, 코드의 특정 부분이 왜 그렇게 쓰였는지 의미를 추적하기 위하여 사용한다.<ref name="위키백과"/> | ||
| − | ; | + | ;유형별 도구 |
| − | :{|class=wikitable width= | + | |
| − | !align=center width=20%| | + | :{|class=wikitable width=1000 style="background-color:white; margin:0 auto;" |
| − | !align=center| | + | !align=center width=20%|분류 |
| + | !align=center|내용 | ||
|- | |- | ||
|align=center|[[CVS]] | |align=center|[[CVS]] | ||
|align=left|[[서버]]와 [[클라이언트]]로 구성되어 다수의 인원이 동시에 범용적인 [[운영체제]]로 접근 가능하여 버전 관리는 가능하게 한다. [[클라이언트]]가 [[이클립스]] 내에 내장되어 있다. | |align=left|[[서버]]와 [[클라이언트]]로 구성되어 다수의 인원이 동시에 범용적인 [[운영체제]]로 접근 가능하여 버전 관리는 가능하게 한다. [[클라이언트]]가 [[이클립스]] 내에 내장되어 있다. | ||
|- | |- | ||
| − | |align=center|[[ | + | |align=center|[[서브버전]](SVN) |
| − | |align=left|[[GNU]]의 버전 관리 시스템으로 CVS의 장점은 이어받고 단점은 개선하여 2000년에 발표되었다. 사실상 업계 표준으로 사용되고 있으며 | + | |align=left|[[GNU]]의 버전 관리 시스템으로 CVS의 장점은 이어받고 단점은 개선하여 2000년에 발표되었다. 사실상 업계 표준으로 사용되고 있으며 'SVN'으로 불리고 있다. |
|- | |- | ||
|align=center|[[RCS]] | |align=center|[[RCS]] | ||
| 26번째 줄: | 27번째 줄: | ||
|- | |- | ||
|align=center|[[바이크 키퍼]] | |align=center|[[바이크 키퍼]] | ||
| − | |align=left| | + | |align=left|[[서브버전]](SVN)과 비슷한 중앙통제 방식의 버전 컨트롤 툴로서 대규모 프로젝트에서 빠른 속도를 내도록 개발되었다. |
|- | |- | ||
|align=center|[[깃]] | |align=center|[[깃]] | ||
| 33번째 줄: | 34번째 줄: | ||
|align=center|[[클리어 케이스]] | |align=center|[[클리어 케이스]] | ||
|align=left|IBM에서 제작되었다. 복수 서버, 복수 클라이언트 구조이며 서버가 부족할 때 필요한 서버를 하나씩 추가하여 확장성을 기할 수 있다. | |align=left|IBM에서 제작되었다. 복수 서버, 복수 클라이언트 구조이며 서버가 부족할 때 필요한 서버를 하나씩 추가하여 확장성을 기할 수 있다. | ||
| + | |- | ||
| + | |align=center colspan=2|유형별 버전관리는 현재 하고 있는 업무에서 다양하게 쓰인다.<ref>codedragon, 〈[https://codedragon.tistory.com/5350 버전 관리 도구의 유형별 특징]〉, 《티스토리》, 2021-02-19</ref> | ||
|} | |} | ||
| 38번째 줄: | 41번째 줄: | ||
;로컬 VCS | ;로컬 VCS | ||
서버 없이 로컬 컴퓨터 내에서 버전을 관리한다. 간단한 [[데이터베이스]]만으로도 구현이 가능하므로 단순하고 개인적인 프로젝트에 적합하다. 단, 협업에서 쓰기에는 힘들고, 컴퓨터가 고장 나는 등 내부 정보가 통째로 날아가 버리면 복구할 방법이 없다. | 서버 없이 로컬 컴퓨터 내에서 버전을 관리한다. 간단한 [[데이터베이스]]만으로도 구현이 가능하므로 단순하고 개인적인 프로젝트에 적합하다. 단, 협업에서 쓰기에는 힘들고, 컴퓨터가 고장 나는 등 내부 정보가 통째로 날아가 버리면 복구할 방법이 없다. | ||
| + | |||
;중앙집중식 VCS | ;중앙집중식 VCS | ||
서버에 최종본 한 벌이 있으며, 사용자들은 이 중 수정을 원하는 파일만 로컬에 받아 수정한 후 서버에 올리게 된다. 간단한 방법으로 협업이 가능하고 관리자가 누가 어떤 일을 하고 있는지 알기 쉬운 장점이 있다. 단, 중앙 서버가 다운될 경우 그동안은 업무가 마비되는 단점이 있다. 그리고 서버의 정보가 날아갈 경우 모든 히스토리가 날아가게 된다. 협업의 규모가 커지면 수정 충돌 문제 등이 발생할 수 있다. 비유해보면 이 나무위키의 문서 편집 시스템이 간단한 중앙집중식 버전 관리에 속한다. 대표적으로 서브 버전이 있다. | 서버에 최종본 한 벌이 있으며, 사용자들은 이 중 수정을 원하는 파일만 로컬에 받아 수정한 후 서버에 올리게 된다. 간단한 방법으로 협업이 가능하고 관리자가 누가 어떤 일을 하고 있는지 알기 쉬운 장점이 있다. 단, 중앙 서버가 다운될 경우 그동안은 업무가 마비되는 단점이 있다. 그리고 서버의 정보가 날아갈 경우 모든 히스토리가 날아가게 된다. 협업의 규모가 커지면 수정 충돌 문제 등이 발생할 수 있다. 비유해보면 이 나무위키의 문서 편집 시스템이 간단한 중앙집중식 버전 관리에 속한다. 대표적으로 서브 버전이 있다. | ||
| + | |||
;분산 VCS | ;분산 VCS | ||
| − | 파일을 저장하는 서버가 있는 것은 동일하지만 수정을 위해 프로젝트 전체를 로컬에 다운받은 뒤 수정한다. 중앙 서버가 다운되더라도 개별 사용자들은 작업이 가능하고 서버가 날아가도 다운받은 내용은 남아있기 때문에 가장 안정적이다. 수정 시에도 현재 코드는 나 혼자 수정하고 있기 때문에 충돌의 염려 없이 수정할 수 있으며, 최종적으로 서버에 올릴 때만 신경 써서 연결해주면 된다. 대표적으로 깃이 있다..<ref>〈[https://namu.wiki/w/%EB%B2%84%EC%A0%84%20%EA%B4%80%EB%A6%AC%20%EC%8B%9C%EC%8A%A4%ED%85%9C 버전 관리 시스템]〉, 《나무위키》 | + | 파일을 저장하는 서버가 있는 것은 동일하지만 수정을 위해 프로젝트 전체를 로컬에 다운받은 뒤 수정한다. 중앙 서버가 다운되더라도 개별 사용자들은 작업이 가능하고 서버가 날아가도 다운받은 내용은 남아있기 때문에 가장 안정적이다. 수정 시에도 현재 코드는 나 혼자 수정하고 있기 때문에 충돌의 염려 없이 수정할 수 있으며, 최종적으로 서버에 올릴 때만 신경 써서 연결해주면 된다. 대표적으로 깃이 있다..<ref>〈[https://namu.wiki/w/%EB%B2%84%EC%A0%84%20%EA%B4%80%EB%A6%AC%20%EC%8B%9C%EC%8A%A4%ED%85%9C 버전 관리 시스템]〉, 《나무위키》</ref> |
{{각주}} | {{각주}} | ||
| 47번째 줄: | 52번째 줄: | ||
== 참고 자료 == | == 참고 자료 == | ||
*〈[https://ko.wikipedia.org/wiki/%EB%B2%84%EC%A0%84_%EA%B4%80%EB%A6%AC 버전관리]〉, 《위키백과》 | *〈[https://ko.wikipedia.org/wiki/%EB%B2%84%EC%A0%84_%EA%B4%80%EB%A6%AC 버전관리]〉, 《위키백과》 | ||
| + | *〈[https://namu.wiki/w/%EB%B2%84%EC%A0%84%20%EA%B4%80%EB%A6%AC%20%EC%8B%9C%EC%8A%A4%ED%85%9C 버전 관리 시스템]〉, 《나무위키》 | ||
*codedragon, 〈[https://codedragon.tistory.com/5350 버전 관리 도구의 유형별 특징]〉, 《티스토리》, 2021-02-19 | *codedragon, 〈[https://codedragon.tistory.com/5350 버전 관리 도구의 유형별 특징]〉, 《티스토리》, 2021-02-19 | ||
| − | |||
| − | == | + | == 같이 보기 == |
| − | *[[CVS]] | + | * [[CVS]] |
| − | *[[ | + | * [[서브버전]] |
| − | *[[RCS]] | + | * [[RCS]] |
| − | *[[바이크 키퍼]] | + | * [[바이크 키퍼]] |
| − | *[[깃]] | + | * [[깃]] |
| − | *[[클리어 케이스]] | + | * [[클리어 케이스]] |
| − | |||
{{소프트웨어|검토 필요}} | {{소프트웨어|검토 필요}} | ||
2021년 3월 2일 (화) 22:18 기준 최신판
버전관리(Version Control, Revision Control)는 정보 및 통신 프로그램의 소스 코드, 문서, 그래픽 및 관련 파일들을 대단위 소프트웨어로 묶어서 개발 시점으로 표기하여 관리하는 시스템이다. 버전 관리 소프트웨어는 해당 프로그램의 모든 프로그래머 및 개발자들이 프로그램을 개정한 사항들을 추적하는 데 사용되는 데이터베이스를 제공한다.
개요[편집]
버전관리는 동일한 정보에 대한 여러 버전을 관리하는 시스템이다. 공학과 소프트웨어 개발에서 팀 단위로 개발 중인 소스 코드나, 청사진 같은 설계도 등의 디지털 문서를 관리하는 데 사용된다. 그러한 문서의 변경 사항들에 숫자나 문자로 이루어 졌으며, '개정판 번호' 및 '개정판 레벨'이라고도 불리는 버전을 부여해서 구분한다. 버전을 통해서 시간상으로 변경 사항과 그 변경 사항을 작성한 작업자를 추적할 수 있다. 간단한 버전 관리 방법으로는 처음 작성한 코드에 버전 번호 1을 부여한다. 변경 사항이 생기면, 버전 번호를 2로 증가시킨다. 이처럼 추후 변경 사항을 발견 시마다 버전 번호를 1씩 증가시킨다.[1]
특징[편집]
- 사용 방식
A가 어떤 파일을 저장소에 추가한다. 추가되었던 파일을 A가 인출한다. 갑돌이가 인출된 파일을 수정한 다음, 저장소에 예치하면서 설명을 붙인다. 다음날 B가 자신의 작업 공간을 동기화한다. 이때 갑돌이가 추가했던 파일이 전달된다. B가 추가된 파일의 수정 기록을 보면서 갑돌이가 처음 추가한 파일과 이후 변경된 파일의 차이를 본다.[1]
- 필요성
거의 대부분의 주요 소프트웨어 개발 프로젝트는 아직도 소프트웨어의 설계도라 할 수 있는 소스 코드 작성이 주요한 부분이 되며 이러한 소스 코드는 기업체 또는 연구소의 핵심 역량이 응축된 핵심 자산이다. 따라서 어떤 형태로든 소스 코드를 백업하여 분실의 위험에서 보호하고 개정 전후 내용을 파악하여 추후 발생할지도 모를 오류 수정에 대비하는 절차가 필요하다. 버전 관리 소프트웨어는 조직의 핵심 자산인 소스 코드의 개정과 백업 절차를 자동화하여 오류 수정 과정을 도와줄 수 있는 시스템으로 이미 다수의 국제 협력 개방 소프트웨어 개발 실무에서도 널리 사용되고 있다. 다음은 버전 관리 시스템을 사용하는 원인을 정리한 것이다. 무언가 잘못되었을 때 복구를 돕기 위하여 또는, 프로젝트 진행 중 과거의 어떤 시점으로 돌아갈 수 있게 하려고 사용된다. 여러 사람이 같은 프로젝트에 참여할 경우, 각자가 수정한 부분을 팀원 전체가 동기화하는 과정을 자동화하기 위하여, 소스 코드의 변경 사항을 추적하기 위하여, 소스 코드에서 누가 수정했는지 추적하기 위하여 사용되며, 대규모 수정 작업을 더욱 안전하게 진행하기 위하거나, 가지치기로 프로젝트에 영향을 최소화하면서 새로운 부분을 개발하기 위하여, 접붙이기로 검증이 끝난 후 새로이 개발된 부분을 본류에 합치기 위하여, 많은 오픈 소스 프로젝트에서 어떠한 형태로든 버전 관리를 사용하고 있음으로, 코드의 특정 부분이 왜 그렇게 쓰였는지 의미를 추적하기 위하여 사용한다.[1]
- 유형별 도구
분류 내용 CVS 서버와 클라이언트로 구성되어 다수의 인원이 동시에 범용적인 운영체제로 접근 가능하여 버전 관리는 가능하게 한다. 클라이언트가 이클립스 내에 내장되어 있다. 서브버전(SVN) GNU의 버전 관리 시스템으로 CVS의 장점은 이어받고 단점은 개선하여 2000년에 발표되었다. 사실상 업계 표준으로 사용되고 있으며 'SVN'으로 불리고 있다. RCS CSV와 달리 소스 파일의 수정을 한 사람만으로 제한하여 다수의 사람이 파일의 수정을 동시에 할 수 없도록 파일을 잠금하는 방식으로 버전 컨트롤을 수행한다. 바이크 키퍼 서브버전(SVN)과 비슷한 중앙통제 방식의 버전 컨트롤 툴로서 대규모 프로젝트에서 빠른 속도를 내도록 개발되었다. 깃 기존 리눅스 커널의 버전 컨트롤을 하는 바이크 키퍼를 대체 하기 위해서 나온 새로운 버전 컨트롤로 현재의 리눅스는 이것을 통해 버전 컨트롤이 되고 있다. 깃은 속도에 중점을 둔 분산형 버전 관리 시스템이며, 대형 프로젝트에서 효과적으로 실제로 유용하다. 클리어 케이스 IBM에서 제작되었다. 복수 서버, 복수 클라이언트 구조이며 서버가 부족할 때 필요한 서버를 하나씩 추가하여 확장성을 기할 수 있다. 유형별 버전관리는 현재 하고 있는 업무에서 다양하게 쓰인다.[2]
종류[편집]
- 로컬 VCS
서버 없이 로컬 컴퓨터 내에서 버전을 관리한다. 간단한 데이터베이스만으로도 구현이 가능하므로 단순하고 개인적인 프로젝트에 적합하다. 단, 협업에서 쓰기에는 힘들고, 컴퓨터가 고장 나는 등 내부 정보가 통째로 날아가 버리면 복구할 방법이 없다.
- 중앙집중식 VCS
서버에 최종본 한 벌이 있으며, 사용자들은 이 중 수정을 원하는 파일만 로컬에 받아 수정한 후 서버에 올리게 된다. 간단한 방법으로 협업이 가능하고 관리자가 누가 어떤 일을 하고 있는지 알기 쉬운 장점이 있다. 단, 중앙 서버가 다운될 경우 그동안은 업무가 마비되는 단점이 있다. 그리고 서버의 정보가 날아갈 경우 모든 히스토리가 날아가게 된다. 협업의 규모가 커지면 수정 충돌 문제 등이 발생할 수 있다. 비유해보면 이 나무위키의 문서 편집 시스템이 간단한 중앙집중식 버전 관리에 속한다. 대표적으로 서브 버전이 있다.
- 분산 VCS
파일을 저장하는 서버가 있는 것은 동일하지만 수정을 위해 프로젝트 전체를 로컬에 다운받은 뒤 수정한다. 중앙 서버가 다운되더라도 개별 사용자들은 작업이 가능하고 서버가 날아가도 다운받은 내용은 남아있기 때문에 가장 안정적이다. 수정 시에도 현재 코드는 나 혼자 수정하고 있기 때문에 충돌의 염려 없이 수정할 수 있으며, 최종적으로 서버에 올릴 때만 신경 써서 연결해주면 된다. 대표적으로 깃이 있다..[3]
각주[편집]
참고 자료[편집]
- 〈버전관리〉, 《위키백과》
- 〈버전 관리 시스템〉, 《나무위키》
- codedragon, 〈버전 관리 도구의 유형별 특징〉, 《티스토리》, 2021-02-19
같이 보기[편집]
