Snap Shot
Git과 SVN은 두 가지 다른 버전 관리 방식을 사용합니다. Git은 SnapShot 방식을 사용하고, SVN은 델타 방식을 사용합니다.
이 두 방식의 핵심적인 차이점은 파일의 변화를 어떻게 추적하고 저장하는지에 있습니다
델타 방식은 각 파일의 버전을 생성할때, 파일 전체를 저장하고, 이후 해당 파일에 발생하는 모든 수정사항, 즉 변경점을 저장합니다.
예를들어, 파일 C가 버전 1에서 생성되었다면, 버전 1의 파일 C 전체가 저장됩니다. 이후 버전 2,3,4에서 파일 C가 수정되었다면, 해당 버전에서의 파일 C에 대한 변경사항만을 저장합니다. 따라서 버전 5의 파일 C를 보려면, 버전 1의 원본 파일에 버전 2,3,4에서의 변경점을 순서대로 적용해야 합니다. 이러한 방식의 문제점은, 커밋이 수만개인 큰 프로젝트를 다룰 때, 특정 버전의 파일을 보려면 모든 변경사항을 순서대로 적용해야 하므로 시간이 많이 걸릴 수 있다는 것입니다.
스냅샷 방식은 각 버전에서 파일의 최종 상태를 직접 저장합니다.
예를 들어, 버전 4에서 파일 A, B, C가 있고, 버전 5에서 파일 B와 C만 변경되었다면, 버전 5의 스냅샷은 다음과 같이 저장됩니다. 파일 A는 버전 4의 파일 A를 그대로 참조하고, 파일 B와 C는 각각의 최신 버전이 저장됩니다.
이러한 방식은, 특정 버전의 파일을 보기 위해 모든 변경사항을 순서대로 적용할 필요가 없다는 것입니다. Git은 단순히 해당 버전의 파일을 직접 참조하면 되기 때문에, 크기가 크고 커밋이 많은 프로젝트에서도 빠르게 작업을 할 수 있습니다.
분산 버전 관리
CVS와 Subversion 같은 중앙 집중형 버전 관리 시스템에서는 중앙 서버에 모든 변경 내역이 저장되고, 참여하는 개발자들은 이 중앙 서버로부터 최신 버전의 파일들을 다운로드 받아 사용합니다. 이런 시스템의 특징은 개발자들이 직접 파일을 수정하고자 할 때마다 중앙 서버에 연결되어야 있어야 한다는 것입니다. 즉 서버와의 연결이 끊기거나, 서버에 문제가 발생할 경우 개발자들이 작업을 진행할 수 없게 됩니다. 또한 모든 히스토리가 중앙 서버에만 저장되어 있기에, 이 서버가 손상되면 모든 버전 관리 내역을 잃어버릴 수 있습니다.
반면 Git과 같은 분산 버전 관리 시스템에서는, 개발자들이 git clone 명령어를 사용하여 원격 저장소를 복제할때, 파일의 현재 버전 뿐만 아니라 모든 커밋 히스토리와 브랜치 정보까지 포함된 전체 저장소를 로컬에 복제합니다. 이 방식의 장점은, 인터넷 연결이 없거나 서버에 문제가 있어도 개발자들이 로컬에서 자유롭게 작업할 수 있다는 것입니다. 모든 커밋 히스토리와 브랜치 정보가 로컬에 저장되어 있기 때문에, 로컬에서 커밋, 브랜치 생성 및 전환, 병합 등의 작업을 오프라인 상태에서도 수행할 수 있습니다
또한, 모든 개발자가 전체 저장소를 가지고 있기 때문에, 한 개발자의 컴퓨터가 문제를 일으키더라도 다른 개발자의 저장소에서 히스토리를 복구할 수 있습니다. 이는 Git이 높은 내구성을 제공한다는 점을 의미합니다
Git의 3가지 공간
Git에서는 파일의 상태를 크게 3가지로 분류합니다. 이 3가지 상태는 파일이 Git에 의해 어떻게 관리되고 있는지를 나타냅니다.
Working Directory : 작업 디렉토리는 개발자가 실제로 작업하고 있는 공간입니다. 여기에서 파일을 새로 생성하거나 기존 파일을 수정하면, 그 파일들은 Working Directory에 위치한 상태가 됩니다. 이때 Working Directory에서 파일의 상태는 다시 두 가지로 나뉩니다.
UnTracked 상태의 파일들은 Git이 이전에 본적이 없는 새로운 파일이거나,. gitignore 파일에 의해 Git의 추적에서 제외된 파일입니다. 이러한 파일들은 아직 Git에 의해 관리되지 않고 있는 상태입니다.
반면 Tracked 상태는 Git이 이전에 본적이 있는 파일로, 이전의 커밋에 포함되었던 파일이거나 git add 명령어를 통해 추적 대상에 추가된 파일입니다. 이러한 파일들은 Git에 의해 관리되고 있는 상태입니다.
Staging Area : 스테이징 영역은 커밋을 준비하는 임시 공간입니다. 개발자는 git add 명령어를 사용하여 Working Directory의 파일들을 스테이징 영역에 추가하고, 이렇게 추가된 파일들은 다음 커밋에 포함될 준비가 된 상태입니다
Repository : 리포지토리는 파일의 바뀐 내용들이 모두 커밋된 상태를 나타냅니다. 즉 파일이 어떤 버전에 포함되어 있다는 것을 의미합니다. git commit 명령어를 실행하면, 스테이징 영역의 모든 파일들이 커밋되어 리포지토리에 저장됩니다.
git restore --staged "파일 명"커밋을 위해 Staging Area에 올렸지만, 특정 파일은 나중에 커밋하고 싶어 Staging Area에서 빼고 싶다면 위와 같은 명령어를 사용하면 됩니다.
만약 위에서 --staged 옵션을 뺀다면 해당 파일은 최신 커밋 상태로 작업 디렉터리에서 복원됩니다.
즉, Working Directory에서 직접 파일에 대해 변경한 내용이 있다면, git restore + 파일명 을 통해 그 변경 내용을 버리고 최신 커밋 상태로 되돌릴 수 있는 것입니다. 이는 아직 커밋되지 않은 변경사항을 취소하고 싶을 때 유용하게 사용될 수 있습니다!
'Git&GitHub' 카테고리의 다른 글
| 커밋 관리하기(커밋 컨벤션, hunk, stash, 과거 커밋 수정,삭제,병합,분할) (0) | 2023.06.23 |
|---|---|
| Git 심화개념 - 2(HEAD, Fetch vs Pull) (0) | 2023.06.23 |
| Branch(merge, rebase, collision 해결) (0) | 2023.06.23 |
| git add, commit, reset, revert (0) | 2023.06.22 |
| Git 최초 설정 및 프로젝트 관리 (0) | 2023.06.22 |
