GIT: Version Control System(버전 관리 시스템)

1. VCS(Version Control System)정의

 1.1. 파일 변화를 시간에 따라 기록

 1.2. 추후 특정 시점의 버전 재사용 가능.

 1.3. 실제로 거의 모든 컴퓨터 파일의 버전을 관리 가능

 

2. 효용성

 2.1. VCS로 이미지나 레이아웃의 버전(변경 이력 혹은 수정 내용)을 관리가능.

 2.2. VCS를 사용하면 각 파일을 이전 시점 회귀,

 2.3. 프로젝트 전체를 이전 시점으로 회귀,

 2.4. 시간에 따른 수정 내용 비교,

 2.5. 이슈자 추적 가능,

 2.6. 누가 언제 이슈를 생성했는지

 2.7. VCS를 사용하면 손쉬운 파일 복구 가능

 

3. 종류

 3.1. RCS(Revision Control System)

  3.1.1. 오늘날까지도 아직 많은 기업에서 사용.

  3.1.2. RCS는 기본적으로 Patch Set(파일에서 변경되는 부분)을 관리.

  3.1.3. Patch Set은 특별한 형식의 파일로 저장.

  3.1.4. 일련의 Patch Set을 적용해서 모든 파일을 특정 시점으로 되돌릴 수 있음.

참조: https://git-scm.com/book/ko/v2/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-%EB%B2%84%EC%A0%84-%EA%B4%80%EB%A6%AC%EB%9E%80%3F

 3.2. CVCS

  3.2.1. 탄생배경: 프로젝트를 진행하다 보면 다른 개발자와 함께 작업해야 하는 경우가 많다. 이럴 때 생기는 문제를 해결    3.2.2. CCVS, Subversion, Perforce 같은 시스템은 파일을 관리하는 서버가 별도로 있고 클라이언트가 중앙 서버에서 파   일을 받아서 사용(Checkout)

  3.2.1. 장점

   3.2.1.1. 모든 참여자가 누가 무슨 작업하는지 관찰가능.

   3.2.1.2. 관리자는 전체 참여자의 작업현황 및 관리가능.

   3.2.1.3. 관리가 용이하다: 모든 클라이언트의 로컬 데이터베이스를 관리하는 것보다 VCS 하나를 관리하기가 훨씬 쉽다.

 

  3.2.2. 단점

   3.2.2.1. 중앙 서버에 발생한 문제다. 만약 서버가 한 시간 동안 다운되면 그동안 아무도 다른 사람과 협업할 수 없고 사람들이 하는 일을 백업할 방법도 없다.

   3.2.2.2. 중앙 데이터베이스가 있는 하드디스크에 문제가 생기면 프로젝트의 모든 히스토리를 잃는다. 물론 사람마다 하나씩 가진 스냅샷은 괜찮다. 로컬 VCS 시스템도 이와 비슷한 결점이 있고 이런 문제가 발생하면 모든 것을 잃는다

참조: https://git-scm.com/book/ko/v2/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-%EB%B2%84%EC%A0%84-%EA%B4%80%EB%A6%AC%EB%9E%80%3F

 

 3.3. DVCS

  3.3.1. Git, Mecurial, Bazaar, Darcs 같은 DVCS에서의 클라이언트는 단순히 파일의 마지막 스냅샷을 Checkout 하지 않음

  3.3.2. 저장소를 히스토리와 더불어 전부 복제.

  3.3.3. 서버에 문제가 생기면 이 복제물로 다시 작업을 시작.

  3.3.4. 클라이언트 중에서 아무거나 골라도 서버를 복원할 수 있다. Clone은 모든 데이터를 가진 진정한 백업이다.

  3.3.5. 대부분의 DVCS 환경에서는 리모트 저장소가 존재한다. 리모트 저장소가 많을 수도 있다.

  3.3.6. 참여자들은 동시에 다양한 그룹과 다양한 방법으로 협업 가능.

  3.3.7. 계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 워크플로를 다양하게 사용가능.

참조: https://git-scm.com/book/ko/v2/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-%EB%B2%84%EC%A0%84-%EA%B4%80%EB%A6%AC%EB%9E%80%3F