title | teaching | exercises | questions | objectives | keypoints | |||||
---|---|---|---|---|---|---|---|---|---|---|
자동화된 버젼제어 |
5 |
0 |
|
|
|
누군가 무엇을 했는지, 언제 했는지를 추적하기 위해서, 버젼제어를 어떻게 사용할 수 있는지 탐색해보자. 다른 사람과 협업을 하지 않더라도, 자동화된 버젼제어가 다음 상황보다 훨씬 더 낫다:
"Piled Higher and Deeper" by Jorge Cham, http://www.phdcomics.com
이전에 상기와 같은 상황에 처했었다: 같은 문서에 대해서 거의 동일한 다수 버젼을 관리하는 것은 우스워 보인다. 일부 워드프로세서가 이런 상황을 좀더 잘 처리하도록 하는 기능이 있다. 예를 들어, 마이크로소프트 워드 "변경사항 추적(Track Changes)" 혹은 구글 닥스(Google Docs)의 버젼 이력이 그것이다.
버젼제어 시슽메은 문서의 기본 버젼으로 시작하고 나서, 각 단계마다 변경한 이력을 저장한다. 테이프로 생각하면 쉽다: 테이프를 되감으면, 문서 시작한 지점으로 가고, 각 변경사항을 다시 돌리면 가장 최근 버젼이 된다.
변경사항을 문서 그자체로부터 떨어진 것으로 생각하면, 동일 기반 문서에 다른 변경사항을 "재생(playback)"하고, 다른 문서 버젼을 관리하는 것으로 간주할 수 있다. 예를 들어, 사용자 두명이 같은 문서에 독립적인 변경 작업을 수행할 수 있다.
만약 충돌나지 않으면, 심지어 동일 문서에서 두가지 변경사항을 작업할 수도 있다.
버젼제어 시스템은 사용자를 대신해서 변경사항을 기록하고, 파일 버젼을 생성하고 파일병합하는데 유용한 도구다. 버젼제어 시스템은 어떤 변경사항을 다음 버젼에 반영([커밋(commit)]({{ page.root }}/reference#commit))으로 불림)할지 결정하는 할 수 있게 하고, 커밋에 관한 유용한 메타정보를 보관한다. 특정 프로젝트와 프로젝트 메타정보에 대한 완전한 커밋이력은 [저장소(repository)]({{ page.root }}/reference#repository)에 보관된다. 저장소는 협업하는 여러 동료 컴퓨터에 걸쳐 동기화될 수 있다.
자동화된 버젼제어 시스템이 새로운 것은 전혀 아니다. 1980년부터 RCS, CVS, Subversion 같은 도구가 존재했고, 많은 대기업에서 사용되고 있다. 하지만, 다양한 기능의 한계로 인해서 이들 중 다수는 이제 레거시 시스템(legacy system)으로 간주된다. 최근에 등장한 도구 Git과 Mercurial은 분산(distributed) 기능을 제공한다. 저장소를 굳이 중앙 서버에 둘 필요가 없다는 의미다. 이러한 최신 시스템에는 동시간에 동일한 파일에 다수 저작자가 작업하는 것을 가능하게 하는 강력한 병합(merge) 도구도 내장하고 있다.
{: .callout}
논문을 작성하면서 정말 멋진 문단을 초안을 작성했지만, 나중에 망치게 되었다고 상상해 보자. 어떻게 정말 멋진 맺음말 버전이 포함된 문서를 되살릴 수 있을까? 가능하기도 할까?
공저자가 5명이라고 상상해보자. 공저자가 논문에 반영한 변경사항과 코멘트를 어떻게 관리할 수 있을까? 마이크로소프트 워드나 리브레오피스 Writer를 사용하는 경우,
Track Changes
옵션을 사용해서 변경한 것을 반영하게 되면 어떻게 될까? 이러한 변경사항에 대한 이력은 갖고 있는가?
{: .challenge}