본문 바로가기

Project Management/Git & Github

[Chapter 2.5] git의 기본 작동 원리 - stage, commit, 그리고 스냅샷

github logo image

 

 

 

이번 아티클에서는 본격적으로 브랜치를 활용한 협업 방식에 대해서 알아보기 전에, git의 기본적인 작동원리와 파일 추적 프로세스에 대해서 알아보고자 합니다. 지금까지 간단하게 알아본 사용법 만으로는 git의 다양하고 복잡한 기능들을 이해하기에는 한계가 있기 때문이죠.

 

 

○ 스냅샷 방식

 

우선, git의 작동방식은 기본적으로 스냅샷(snapshot) 방식입니다. 이 스냅샷 방식이 어떻게 동작하는지, 그리고 스냅샷 방식이 아닌 경우에는 어떤 식으로 동작하는지에 대해 텍스트 파일에 변화가 생겼을 때 버전을 기록하는 방식으로 구분해 보겠습니다. 

 

git에서 채택하고 있는 스냅샷 방식은 하나의 파일에 변동이 생겼을 때, 파일의 상태 "전체"를 그대로 저장해 비교합니다. 

스냅샷 방식. 변화가 생기면 통째로 기록한다

 

 

반대로 SVN 같은 시스템에서는 델타(delta) 방식을 사용합니다. 이는, 파일에 어떤 변화가 생겼을 때 "변화된 사항"만 기록하는 방식입니다. 

 

델타 방식. 변화가 생기면 차이점만 기록한다

 

 

언뜻 생각하기에는 델타 방식이 합리적일 것 같습니다. 스냅샷 방식은 변화가 생길 때마다 통째로 기록한다니 용량이나 처리가 복잡할 것 같다는 생각이 들지요. '차이점만 관리하면 되지 않나?'라는 생각이 듭니다. 

 

하지만 잘 생각해봐야 합니다. 만일 파일이 100번 수정이 되었다고 가정해 보겠습니다. 예를 들어 '52번째 수정되었을 때의 파일 상태'를 불러와서 봐야한다고 가정하면, 1번 상태에서부터 52번까지 변화를 모두 연산해 반영하고 52번째 파일의 전체 상태를 보여줘야 합니다. 아, 생각이 바뀌어서 갑자기 60번째 변화에서의 파일을 보고 싶어 졌습니다. 그럼 다시 1번부터 60번까지의 변화를 적용해서 다시 산출해야 합니다. 

 

하지만 스냅샷 방식으로 각 버전을 통째로 기록해 두었다면? '52번째 수정되었을 때의 파일 상태'를 불러오려면 바로 52번째 기록을 불러오기만 하면 됩니다. 다시 60번째 버전으로 가고 싶으면, 바로 60번째 기록을 불러오기만 하면 됩니다. 버전별로 차이점을 보고 싶을 때는 두 개의 스냅샷을 비교해주기만 하면 됩니다. 버전관리에 좀 더 용이한 방식인 것이죠. 

 

 


 

 

○ 스냅샷 방식과 add와 commit 실행 방식, 그리고 스테이지(stage)

 

자, 위에서 말씀드린 스냅샷 방식은 이해가 가셨을 겁니다. 그럼 우리가 git 명령어를 통해 기본적으로 파일을 등록하고 커밋을 생성하던 add, commit 명령어의 동작 방식과 git에서 중요한 '스테이지' 개념을 그림과 함께 살펴보겠습니다. 

 

방송 무대('stage')가 있고, 여기에 연습생들 중에서 아이돌그룹 멤버를 선발해 멤버로 선발한다고 가정해 보겠습니다. 멤버가 변할 때 마다 사진을 찍어서 남겨두고, 아이돌 그룹 멤버가 확정될 때까지 얼마나 많은 변화가 있었는지를 기록하려고 합니다. 해당 아이돌 그룹 멤버의 결성 과정은 다음과 같습니다. 

 

1. 멤버 A가 최초로 확정
2. 멤버 B가 합류함
3. 멤버 C가 합류함
4. 멤버 B가 탈퇴함
5. 멤버 D가 B의 자리로 합류함
6. 멤버 A가 다이어트를 해서 30kg를 감량함

 

멤버에 변화가 생길때마다, 무조건 무대(스테이지)에 올려서 한 번씩 프로필 사진을 찍었습니다. 그렇게 사진을 찍다 보니 사진이 총 6장이 나왔습니다. 이렇게 매번 무대에 올려서 프로필 사진을 찍은 기록을 정리해 보면 아래와 같습니다. 

 

아이돌 그룹 프로필 사진과 스냅샷의 관계

 

 

자, 이제 눈치가 빠른 분들이라면 알아채셨겠지만 이 과정은 git에서 add, commit을 진행하는 과정을 그림으로 나타낸 것과 같습니다.

 

- 멤버에 변동이 생겨 스테이지에 멤버를 올리는 것 : add

- 멤버의 프로필 사진을 한 번 찰칵! 찍는 것 : commit

 

그럼 6장의 사진은 곧 6개의 commit을 의미하게 됩니다. 만일 사장이 최신 상태에서 "세 번째 ABC일 때가 좋았던거 같지 않아? 그때로 돌려봐"라고 말한다면, 바로 3번 사진의 상태로 멤버를 되돌리는 것이죠(가혹해라;;).

 

이번 아티클에서 이 개념을 자세하게 설명한 이유는, 이를 실제 파일 - 로컬 저장소 - 스테이지 - 원격 저장소에 적용하여 실제 파일이 관리되는 용어를 설명하기 위함입니다. 파일 추적과 관련된 자세한 내용은 다음 아티클에서 설명하겠습니다.