제목부터 거부감이 들 수 있을 것 같습니다. 🙂
그래도 제가 문제를 해결한 방식이니 소개해보겠습니다.
최근에 git에 대한 짧은 히스토리를 보게 되었어요. git이 어떤 버전 관리 툴인지 알아 볼까요? 어떤 종류든 파일로 결과물을 남기는 사람들은 버전 관리의 중요성을 알고 있을거라 생각합니다.
이런 복사 + 이름 붙이기가 버전 관리의 시초입니다
아, 저기 최종+찐최종.txt에는 최종-이미지변경.txt의 수정 사항이 반영되어있지 않습니다. 😊 그러면 환수-수정-최종-진짜끝-23일.txt에는 최종-이미지변경.txt의 수정 사항이 반영되어 있을까요?
글쎄요? 전 그냥 최종+찐최종-찐찐최종.txt에서 작업한거라서 잘 모르겠습니다.
도저히 이렇게 관리할 수 없다고 생각한 사람들이 다른 방식의 버전 관리를 도입했습니다.
아주 심플한 database를 만듭니다. 그리고, 작업하는 파일 시스템 전체의 snapshot을 database에 version과 함께 저장하는 거죠. 점점 기능을 추가하고, 각 버전의 업데이트 마다 **변경 사항(Delta based)**만 저장하고, 이를 계산하여 각 버전의 snapshot을 계산하는 형태로 발전했습니다.
Local Version Control 방식의 문제는 여러 사람이 함께 작업하는 환경에서 버전 관리가 아주 번거롭다는 점입니다.
이를 해결하기 위해 하나의 서버에서 database를 관리하고, 각각의 client는 특정 버전의 snapshot을 checkout 하거나, 최고 버전에 대해 각자의 수정 사항을 commit하는 CVCS 형태가 나오게 되었습니다. 여기 유명한 툴은 Subversion, SVN이 있습니다.
CVCS는 완벽했습니다. 프로젝트를 관리하던 서버가 안 켜지기 전까지는 말이죠.
다행히 각자의 작업 PC에 있던 최신 버전의 데이터는 살렸지만, 이제 회사는 옛날 버전의 SW에 대해 지원할 수 없게 됐어요. 회사도 모르거든요.
DVCS 방식은 각각의 client에서 snapshot 뿐만 아니라 history를 포함하여 server의 모든 것을 복사합니다. 모든 기록을 다 받기 때문에 각각의 local repository는 원본인 remote 서버의 역할을 대신할 수도 있습니다.
여기 유명한 툴은 Git이 있습니다. Git에서 clone으로 받은 working tree는 local repository라 부릅니다. CVCS인 SVN에서 commit과 다르게, DVCS의 push, pull은 respository 사이의 동기화 과정이란 뜻이죠.
자! 길고 긴 서론이 끝났습니다.
git은 DVCS이고, SVN은 CVCS입니다. git의 push, pull은 앞서 말했듯 repository 사이에 동기화 과정이죠. 그러니, local repository에서 지운 다음 commit 하더라도, history에 남아 있다면 그 것도 remote repository에 push합니다.