[git] git snapshot

2021. 3. 10. 21:26

특정 시점에서 파일, 폴더 또는 워크스페이스의 상태를 의미합니다.

스냅샷을 통해 특정 시점에 어떤 파일에 어떤 내용이 기록되어 있었는지, 폴더 구조는 어떠했는지, 어떤 파일이 존재했는지 등 저장소의 모든 정보를 확인할 수 있습니다.

Git에서는 새로운 버전을 기록하기 위한 명령인 커밋(commit)을 실행하면 스냅샷이 저장된다.

기존 버전관리 시스템(서브버전, 퍼포스 등)과 깃과의 큰 차이는 버전 데이터를 관리하는 방식입니다.

다른 시스템은 주로 파일을 중심으로 파일이 변경된 내역을 관리하고 있죠.

데이터를 보는 관점이 어떤 파일이 존재하고 각 파일이 시간에따라 변경된 차이점에 있게 됩니다.

이를 델타 베이스드 버전 관리(delta-based version control)이라고 하죠.

프로젝트 처음에 File A, File B, File C로 Vesrion 1을 시작했습니다.

그리고 File A와 File C에 기능을 구현해서 Version 2가 되었습니다.

이때 File A와 File C는 Version 1 대비 변경된 내용이 delta 1으로 저장이 됩니다.

Version 2의 코드를 받아 보려고 하면 원본인 File A와 File C에 변경 사항인 각각의 delta 1을 적용해서 받아오는 겁니다.

이와는 달리 깃은 아주 다르게 데이터가 관리됩니다.

데이터를 바라보는 관점이 완전히 다른데요.

파일을 하나씩 별도로 보면서 차이점만 따로 관리하지 않고 프로젝트 전체를 스냅샷 형태로 관리합니다.

마치 매 순간마다 프로젝트 전체를 사진으로 찍어서 관리하는 것과 같은데요.

Version 1에서 Version 2로 변경이 되면 깃은 Version 2의 스냅샷을 하나 만들어 놓고 그 스냅샷을 가르키는 레퍼런스를 저장합니다.

효율을 위해서 변경되지 않은 File B는 다시 새로 저장을 하는 것이 아니라 이미 저장되어 있는 파일에 링크만 걸어 줍니다.

버전이 변경되는 과정을 보면 마치 연속된 스냅 사진을 보는 것 같습니다.

Git에서 커밋을 하면 워크스페이스 전체가 스냅샷으로 저장되지만 덩치가 배로 불어나지는 않습니다.

Git은 마지막 커밋의 스냅샷만 통째로 저장하고 나머지 커밋에 대해서는 스냅샷과 스냅샷이 차이를 기록한 ‘델타’를 저장하기 때문입니다.

Git의 스냅샷과 델타 구성

이렇게 하면 버전별로 전체 스냅샷을 모두 저장하지 않아도 마지막 스냅샷을 기준으로 특정 시점의 스냅샷을 만들 수 있습니다.

저장소의 크기도 자연히 줄어듭니다. (Git을 개발한 측에서는 VCS 중에서 저장소 크기가 가장 작다고 주장한다

솔직히 아직도 File delta 기반 버젼 관리 vs snapshop 기반 버젼 관리의 차이가 확실히 이해가 되질 않았다.

하지만 아래의 이미지를 보면 좀 더 이해가 될 것이다.

File Delta Version Tracking

• add means add file contents to the snapshot • The SHA hash is a pointer into a key-value store.

• There is no history unless you walk through the manifests.

• A rename just changes the manifest pointer.

git은 snapshot based 버전 관리 시스템이다.
delta bases 버젼 관리 시스템에서 만약 하나의 파일의 거의 대부분을 수정할 일이 생겼다면 delta의 용량도 무시하지 못하게 커질 것이다. 또 version2던 version3던 첫번째 파일에서 시작해 변경점을 적용하면서 접근하기 때문에 제일 최신의 버젼에 접근할 때 속도면에서 손해가 있을 것이다.
하지만 Git은 마지막 커밋의 스냅샷만 통째로 저장하고 나머지 커밋에 대해서는 스냅샷과 스냅샷이 차이를 기록한 ‘델타’를 저장하기 때문입니다.
또 마지막 커밋에서 시작하기 때문에 최근의 커밋에 접근할 때에 자원면에서 손해가 덜 할 것이다...라고 이해했습니다.