버전 관리 시스템의 필요성

신입 개발자에게 팀장님이 file1.txt파일을 수정해! 라고 한것이다. 그래서 신입이 수정을 하고 팀장님께 이메일로 전송했는데 팀장님께서 며칠 있다가 그 file1.txt를 보시더니 '아 ~ 전에 있던 소스코드로 돌려야 할것같은데...?'라는 주문을 받고는 이 신입은 멘붕이 왔다....(퇴사..)

그렇다면 만약에 file1.txt를 처음 받았을때의 형상과 수정했을때의 형상을 둘 다 가지고 있는 마법의 요정 지니가 있다면?! 이 신입은 좀 더 잘 버틸 수 있지 않았을까?..

버전 관리 시스템 vcs

위 이야기에서는 비단 하나의 파일을 수정하는 것에 대한 사건을 얘기했지만 프로그래밍을 하다보면 수백게의 파일에대해서 수정과 추가가 생겨버리는데 이를 관리하고 싶은 욕구가 막 생기지 않을 수가 없다...
그렇게 해서 나온것이 git이라는 프로그램이다.
commit을 하는 순간 하나의 버전이 탄생해서 그 commit의 형상을영구히 저장해 놓는것이다. 그리고 다음버전으로 commit을 하게되면 전체를 복사할 필요없이 수정된 부분면 부분 변경이 된다.
그리고 이 버전관리 시스템의 장점중 하나가 전에 있던 commit지점으로 돌아 갈 수 있다라는 점이다.
하지만 이 vcs도 치명적인 단점이있다.

• 바이러스걸리면 그냥 노답
• 협업이 안됨

중앙 집중형 버전관리 시스템 CVCS

vcs의 단점을 보완하기 위해서 나온 시스템이다.
vcs의 단점인 협업이 안되는 단점을 보완하기위해서 나온 시스템이다.
A와 B가 각자 컴퓨터로 개발을 하다가 C라는 중앙시스템에 파일을 올리는 것이다.
이렇게하면 서로 협업 할 수 있다.
하지만 cvcs도 치명적인 단점이 있다. B가 C컴퓨터에 올린것을 모르고 A가 자기 작업을 C에 올리게 되면 B가 작업한 내용이 다 날라가게 된다는점... 협업을 엄청 잘 해야한다는 점이다.

분산 버전관리 시스템 DVCS(git)

위 상황에서 A가 작업을 해서 v1에서 v2를 업데이트를 한후에 중앙컴퓨터에 올리면 분산버전관리 시스템에서는 이 history를 로컬과 중앙컴퓨터 둘다 가지고 있는다.
중앙에서 전부 관리하는것이 아닌 자신의 로컬컴퓨터에서도 다 관리를 할 수 있게 되는것이다.