8 . 자동화된 버젼제어

누군가 무엇을 했는지, 언제 했는지를 추적하기 위해서, 버젼제어를 어떻게 사용할 수 있는지 탐색해보자. 다른 사람과 협업을 하지 않더라도, 자동화된 버젼제어가 다음 상황보다 훨씬 더 낫다:

이전에 상기와 같은 상황에 처했었다: 같은 문서에 대해서 거의 동일한 다수 버젼을 관리하는 것은 우스워 보인다. 일부 워드프로세서가 이런 상황을 좀더 잘 처리하도록 하는 기능이 있다. 예를 들어, 마이크로소프트 워드 “변경사항 추적(Track Changes)” 혹은 구글 닥스(Google Docs)의 버젼 이력이 그것이다.

버젼제어 시슽메은 문서의 기본 버젼으로 시작하고 나서, 각 단계마다 변경한 이력을 저장한다. 테이프로 생각하면 쉽다: 테이프를 되감으면, 문서 시작한 지점으로 가고, 각 변경사항을 다시 돌리면 가장 최근 버젼이 된다.

변경사항이 순차적으로 저장된다.

변경사항을 문서 그자체로부터 떨어진 것으로 생각하면, 동일 기반 문서에 다른 변경사항을 “재생(playback)”하고, 다른 문서 버젼을 관리하는 것으로 간주할 수 있다. 예를 들어, 사용자 두명이 같은 문서에 독립적인 변경 작업을 수행할 수 있다.

다른 버전이 저장될 수도 있다.

만약 충돌나지 않으면, 심지어 동일 문서에서 두가지 변경사항을 작업할 수도 있다.

버전 다수가 병합될 수도 있다.

버젼제어 시스템은 사용자를 대신해서 변경사항을 기록하고, 파일 버젼을 생성하고 파일병합하는데 유용한 도구다. 버젼제어 시스템은 어떤 변경사항을 다음 버젼에 반영(커밋(commit))으로 불림)할지 결정하는 할 수 있게 하고, 커밋에 관한 유용한 메타정보를 보관한다. 특정 프로젝트와 프로젝트 메타정보에 대한 완전한 커밋이력은 저장소(repository)에 보관된다. 저장소는 협업하는 여러 동료 컴퓨터에 걸쳐 동기화될 수 있다.

버젼제어 시스템의 오랜 역사

자동화된 버젼제어 시스템이 새로운 것은 전혀 아니다. 1980년부터 RCS, CVS, Subversion 같은 도구가 존재했고, 많은 대기업에서 사용되고 있다. 하지만, 다양한 기능의 한계로 인해서 이들 중 다수는 이제 레거시 시스템(legacy system)으로 간주된다. 최근에 등장한 도구 Git과 Mercurial은 분산(distributed) 기능을 제공한다. 저장소를 굳이 중앙 서버에 둘 필요가 없다는 의미다. 이러한 최신 시스템에는 동시간에 동일한 파일에 다수 저작자가 작업하는 것을 가능하게 하는 강력한 병합(merge) 도구도 내장하고 있다.

논문 작성

• 논문을 작성하면서 정말 멋진 문단을 초안을 작성했지만, 나중에 망치게 되었다고 상상해 보자. 어떻게 정말 멋진 맺음말 버전이 포함된 문서를 되살릴 수 있을까? 가능하기도 할까?

• 공저자가 5명이라고 상상해보자. 공저자가 논문에 반영한 변경사항과 코멘트를 어떻게 관리할 수 있을까? 마이크로소프트 워드나 리브레오피스 Writer를 사용하는 경우, Track Changes 옵션을 사용해서 변경한 것을 반영하게 되면 어떻게 될까? 이러한 변경사항에 대한 이력은 갖고 있는가?