Day13_학습정리

로컬 저장소에서의 git 영역

• 작업 디렉토리
  • 실제 파일이 이루어진 곳
• Staging area
  • 영구적으로 저장하기 위해 Staging area에 저장하고 싶은 파일들의 정보를 등록
  • git add 를 통해 작업 디렉토리의 파일들을 staging area에 올려놓을 수 있음
    • 이 때 작업 디렉토리의 파일을 옮기는 것이 아닌, 복사하는 것.
    • 작업 디렉토리의 파일을 수정해도 Staging area의 파일에는 반영되지 않음
• Head(Git Directory)
  • Staging Area에 있는 파일들을 가지고 최종 확정본(commit)을 만들어 커밋을 완료

파일 상태 용어

• staged
  • staging area에 있는 파일들
  • staging area에 있는 파일들을 커밋하게 되면 해당 파일들은 하나의 커밋으로 저장된 후 파일의 상태는 unmodified로 내려오게 됨
  • staging area에서 staged된 상태의 파일
• tracking
  • 파일을 추적하여 파일의 변경을 사용자에게 알려줌
• untracked
  • 추적되지 않는 상태
• modified
  • unmodified 상태의 파일들을 수정하게 되면 변하는 상태
  • 파일의 변경이 이루어짐

SHA(Secure Hash Algorithm)

• 안전한 해시 알고리즘의 표준
• ‘SHA-256’은 Secure Hash Algorithm 256-bit의 줄임말로, 암호학적 해시 함수 중 하나
• 해시 함수 → 임의의 크기를 가진 데이터를 고정된 크기의 해시 값으로 변환하는 함수
• SHA-256은 256비트(32바이트) 길이의 해시 값을 생성하며, 주로 데이터 무결성 검증, 메시디 인증 코드(MAC) 생성, 비밀번호 저장 등 다양한 보안 관련 작업에 사용된다.SHA-256은 입력 데이터의 작은 변화에도 큰 차이를 만들어내기 때문에 데이터의 무결성을 확인하는 데 유용하다.
• SHA-256은 일방향 해시 함수이므로, 해시 값을 통해 **원래 데이터를 복원할 수는 없음.**따라서 주로 비밀번호의 안전한 저장과 비교, 파일의 무결성 검사 등에 활용된다.

Git 뜯어보기

우리가 깃은 협업관리 툴로 많이 쓰지만 정작 이러한 깃의 작동 원리나 내부 구조에 대해서 알아본 적은 거의 없고 앞으로도 없을 사람이 많을 것이다. 하지만 무엇인가를 잘 알기 위해서 구조를 아는 것은 필수적이고, 공부하다보면 계속해서 현업에서도 쓰일 깃의 활용성을 보다 높일 것이다.

깃의 내부구조

깃은 우리가 맨날 init하고 add하고 이것저것 하는데 정작 이 명령어를 통해서 뭐가 어떻게 바뀌는지 모른다. 한번 제대로 알아보자.

Init을 통한 프로젝트 생성

UNIX 운영체제를 기준으로 폴더 이름이나 파일 이름 앞에 .을 붙이면 숨김처리가 된다. 그렇기 때문에 우리가 이러한 init을 통해 뭐가 만들어지는지 모르는 사람도 많았을 것이다.(나도 그랬다) 참고로 맥은 Shift + cmd + . 을 누르면 숨김파일을 볼 수 있다. git init을 하면 .git이라는 디렉토리가 내가 init을 실행한 경로에서 만들어진다.

뭐가 되게 많다. 여기에서 우리가 주목해야 할 것들은 따로 있다.

/Objects

.git/objects .git/objects/info .git/objects/pack 이러한 Objects 디렉토리의 내용들이 가장 중요하다.

처음에 이 디렉토리에는 아무것도 없지만, 우리가 데이터를 add하게 되면 해당 디렉토리로 2가지 글자로 된 디렉토리를 만들고, 그 아래로 38글자의 파일명을 가지는 파일이 각각 들어가 있다.

이 Objects의 구성은 실제 파일에 담긴 값들을 zlib으로 압축한 뒤, SHA1 해시한 값을 2/38글자로 자른 것이다. 해시값은 내용이 똑같지 않은 이상 조금이라도 변동이 생기면 달라지므로 파일 식별이 좋아진다. 따라서 기존 파일에 대한 수정이 이루어졌을 경우 이전 버전과 현재의 버전 두 가지가 함께 저장되어 있다. 그래서 우리는 git revert와 같은 방식으로 이전 커밋 기록 파일을 그대로 가져올 수 있는 것이다.

이 Objects 안에 들어가는 개체는 크게 3가지로 나뉠 수 있다.

• Blob
• Tree
• Commit
• tag(dlc)

Blob

Blob은 대형 이진 객체(Binary Large Object)라는 이름의 약자이다. 닉값 한 듯이 이미지, 사운드, 비디오와 같은 멀티미디어 데이터를 다룰 때 사용하기 좋은 객체이며 JSON과 같은 데이터도 다룰 수 있다. 하지만 이는 바이너리 형태로 큰 객체를 저장하기 때문에 자바스크립트와 같은 데에서도 Blob 객체를 다룰 수도 있지만 ArrayBuffer, ArrayBufferView, File, DOMString 객체와 같은 한정적인 자료구조만 담을 수 있다.

const blob = new Blob([new ArrayBuffer(data),{
	type: "application/json"
})

자바스크립트에선 이러한 식으로 만들 수 있다.

이 객체는 해당 파일의 바이트 크기 size와 MIME 타입을 나타내는 type Property를 가진다.

Tree

트리는 커밋당 하나 이상의 트리를 포함하는 개체이다. Tree의 특이점이라고 한다면, 유닉스 그러니까 우리가 쓰는 리눅스나 맥에서의 파일 시스템과 유사한 구조를 가진다. (하긴 리누스 토르발즈가 만들었으니) 트리는 서브 트리 또는 BLOB객체를 가지며, 이러한 서브 트리의 경우 디렉토리의 구조를 표현하기 위해 사용한다.

$ git cat-file -p master^{tree} //<-- master브랜치가 가리키는 Tree 개체
100644 blob a906cb2a4a904a152e80877d4088654daad0c859      README
100644 blob 8f94139338f9404f26296befa88755fc2598c289      Rakefile
040000 tree 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0      lib <-- 다른 Tree 개체

해당 깃의 Tree객체를 보면 파일 식별자 / 개체 / 해시값 / 파일명으로 되어 있음을 알 수 있다. 여기서 파일 식별자는

• 100644(읽기파일(blob))
• 100755(실행파일(blob))
• 040000 디렉터리(Tree) 를 의미한다. 뒤의 숫자는 파일 시스템모드(권한)을 의미하낟.

Commit

커밋은 부모 커밋에 대한 참조를 공유한다.

이 커밋은 만들어질 때 부모 커밋에 대한 참조를 가져오면서 commit tree를 만들어 커밋 개체에 대한 설명과 Tree 개체의 SHA-1값을 넘긴다.

이 때 이 Tree객체는 최상단 Tree를 하나 가리키는데. username과 user.email 설정에서 가져온 정보, 시간정도, 커밋 메시지가 들어감

깃의 대부분의 객체가 불변 객체인 만큼, commit 객체 또한 불변성(immutable)을 가지고 있으며, 이는 곧 업데이트되지 않는다는 의미기도 하다.

이러한 commit 객체에는

• 작성자
• 커밋 실행자
• 커밋 날짜
• 로그 메시지
• tree 객체 등의 정보를 지닌다.

tag

태그는 꼬리표와 같은 의미를 가진다. 이러한 tag는 우리가 git tag할 때 생성되며, commit 객체명, tag 이름, tagger, 메시지 등이 기록된다. 우리가 자주 쓰지는 않지만 태그를 통해 버전 명 등을 달아서 관리하고 싶을 때 사용하는 옵션이다.

그렇다면 이러한 객체들은 어느 시점에서 생기고, 어떤 시점에서 원격 저장소로 가는 등의 흐름을 알아보자.

깃이 commit 되기까지

기본적으로 깃에서 담겨 있는 데이터들은 파일 시스템 상에서의 스냅샷이다. 즉, 우리가 저장하는 커맨드(커밋)하여 적용할 때의 순간을 중요시한다.

깃 프로젝트는

• Working Directory : 작업할 파일이 있는 디렉토리로 untracked/tracked 상태의 파일들로 나뉘어짐
• Staging Area: 커밋을 수행할 파일들이 올라와있는 영역
• repository : 커밋들이 모여있는 영역 등의 구성요소를 가진다.

해당 사진은 Pro Git에 나오는 파일의 상태 변화도이다. 해당 상태를 따라가보자.

우리가 맨 처음에 git init을 통해 프로젝트를 만들고, 파일을 git add 하게 되면 커밋할 파일들은 Staging area에 추가된다.

하지만 이 파일들은 바로 repository로 가는 것이 아닌, 해당 staging Area에 올라와 있다가 우리가 git commit을 하게 되면 비로소 repository로 가게 된다.

그리고 또 이 commit을 해서 repository로 가기 전까지의 과정에서 맨 처음에는 unmodified 상태로, 신규로 파일이 추가되었을 때를 의미한다. 해당 사진에서는 바로 staged 상태로 직행하는 것처럼 나와있다. 왜냐하면 statged 상태가 Staging Area에 반영된 상태임을 나타내는 상태이기 때문이다.

git add 를 한 뒤로 unmodified 상태였던 파일들은 만약에 수정이 이루어지면 Modified 상태가 되고, 이를 다시 add를 통해서 Staging Area로 다시금 올릴 수 있다.

이러한 Staging Area는 디렉토리 뿐만이 아니라 파일 단위로도 Staging Area에 올려놓을 수 있기 때문에 일부분만 커밋할 때나 일부에서 일어난 충돌을 해제할 때 유용하다.

이렇게 Staging Area에 올린 것들은 git commit을 통해서 해당 커밋에 대해서 Tree Object를 만들고, 이러한 Tree Object를 가리키는 Commit Object를 만들며, 이러한 커밋들을 index라는 파일을 통해 커밋들의 해시값을 관리한다. 이렇게 가는 과정에서

• 개체의 타입을 blob으로 만들면서 헤더를 먼저 만듦
• 공백 문자 하나, 내용의 크기, 마지막에 널 문자를 추가
• 헤더와 원래 내용을 합쳐서 SHA-1 체크섬 계산
• zlib을 통해 내용 압축(zlib-deflate.delfate())
• 압축한 내용을 개체로 저장
  • SHA-1값 중에서 맨 앞에 있는 두 자를 가져다 하위 디렉토리 이름으로 사용
  • 나머지 38자를 그 디렉토리 안에 있는 파일 이름으로 사용
  • fileUtils.mkdir로 디렉토리를 만들고 연 다음에 압축한 내용을 저장 와 같은 파일들의 저장이 이루어지게 된다.