Git internal structure - Git의 내부 구조

hyperskill - Git internal structure 영어 원문

당신이 기억하듯이, Git은 버전 컨트롤 시스템입니다.

그런데, 이러한 정의 뒤에는 무엇이 있죠?

시스템이 어떻게 작동하며, 사용 할 때 왜 이렇게 편리 한 것이죠?

응용 예제에서, 우리는 당신의 프로젝트에서 어떻게 버전을 조정 할 수 있었는지에 대한 상세한 예제들을 보여 줄 겁니다.

하지만 처음으로, 수행 과정에 있어 더 나은 이해를 위해 일반적인 기초 개념에 대해서 말해 봅시다.

git을 작업 할 때 주요한 임무는 프로젝트를 버저닝(versioning) 하는 겁니다.

이를 수행하기 위해서, 당신이 필요 한 것은 :

• 새로운 repository가 선언 된 후, 즉시 생성되는 .git 폴더를 담고 있는 작업 도구.
• 현재 프로젝트의 작업 단계가 무엇인지, 나중에 어디로 가게 되는지 이해하기 위해 파일의 상태를 추적하기.
• 작업이 종료되었을 때 프로젝트 파일에서 만들어진 변경사항을 commit 하기.

따라서, Git work의 로직이 무엇인지 설명하고 있는 세 개의 주요 참고 사항은

.git folder, git commit, git files stages 입니다.

지금부터, 순서에 따라 이러한 개념들을 살펴 봅시다. .git 폴더부터 시작합니다.

.git folder - .git 폴더

---

새로운 repository를 생성 한 후, 당신은 .git 폴더를 가지게 될 겁니다.

이 폴더는 Git을 작업하기 위해 필요한 모든 것을 담고 있습니다.

또한 당신은 프로젝트에서 Git이 더 이상 필요하지 않다면, 이를 삭제 할 수 있습니다.

이후, 프로젝트 파일은 디스크에 남게 될 겁니다.

당신이 처음으로 commit 하기 전에 전형적인 .git 폴더의 콘텐츠가 있습니다 :

• HEAD 는 현재 branch(repo 에 대한) 혹은 최신 commit 에 대한 포인터를 포함하는 파일입니다.
• config - Git repo에 있으며, .git/config 인 파일이 있습니다.
  이 파일은 물론 repo에 대한 상세한 세팅을 포함하고 있습니다.
  이 세팅에는 remote repo URL 을 포함하고 있으며, repo에 관련된 유저의 이름과 이메일을 포함합니다.
  그리고 또 다른 구성 옵션을 포함합니다.
• description 은 Gitweb 인터페이스에서 레포지토리의 설명을 표시하기 위해 사용됩니다.
• hooks - 이 폴더는 Git 실행의 다양한 단계에 있어 실행 될 수 있는 스크립트를 포함하고 있습니다.
  hook의 예시는 repository 에 push 하기 전, style check (스타일 확인) 스크립트를 예시로 들 수 있습니다.
• info-exclude : 당신이 repository에 포함하고 싶지 않아 하는 파일들을 설명 하는 곳입니다.

Git file stages - Git 파일 단계

---

여기 당신의 파일들이 될 수 있는 세 가지의 주요 상태가 있습니다 :

1. commited : 즉, 파일이 이미 당신의 로컬 DB에 저장되었습니다.
2. modified : 즉, 파일에 저장 되지 않은 몇 가지 변경 사항이 있습니다.
3. prepared (staged) : 즉, 수정 된(modified) 파일은 다음 commit에 포함시키도록 표시합니다.

따라서 각각, Git의 설계에 대한 세 가지 주요 개념이 있습니다 :

이는 Git 프로젝트의 세 가지 주요 섹션입니다.

flowchart TB

working-directory("working directory") -- git add --> staging-area("staging area")
staging-area -- git commit --> repository

Git directory (.git) 은 Git이 당신의 프로젝트를 기반으로 메타데이터와 오브젝트를 저장하는 장소입니다.

이는 Git에 있어 가장 중요한 부분인데요, 또 다른 장치에서 당신의 repository를 복제 할 때, 복사됩니다.

working directory 는 프로젝트 버전의 스냅샷(snapshot) 입니다.

snapshot이란, 해당 버전의 상태를 정확하게 포착하여 저장한다! 라는 의미로 받아들이시면 됩니다.

파일들은 압축된 데이터베이스에서 Git 디렉토리로 가며 압축이 풀리고 디스크에 위치합니다.

이후, 당신은 이 파일들을 조정 할 수 있습니다.

staging area 는 당신의 Git 디렉토리에 위치한 파일이며,

다음 commit에 어떤 변경 사항이 가게 될 지에 대한 정보를 담고 있습니다.

이 area를 *"index"* 라고 부르기도 하며, 평범하게 stage area라고 부르기도 합니다.

당신이 파일을 추가 할 때, 처음에는 정확히 index로 가며, 이후엔 오로지 commit 한 후에야 repo에 나타납니다.

위의 내용을 모두 요약 하자면, 기본적인 Git 의 접근법은 이와 같습니다 :

1. 당신은 working directory의 파일을 변경합니다.
2. 당신은 index 에 파일을 추가하며, 이로 인해 staging area에 이들의 snapshot을 추가합니다.
3. 당신이 commit 할 때, index의 파일들을 있는 그대로 사용되며, 이 스냅샷은 당신의 Git directory (.git) 에 저장됩니다.

Git commit - Git 커밋

---

Git의 전체적인 구조는 프로젝트의 최신 버전을 저장해야 한다는 점에 크게 기반합니다.

만약 우리가 Git을 가지지 않고 파일을 작업 한다면 얼마나 불편 할 지 상상 해 보세요.

파일이 변경되었지만, 잘못된 변경으로 인해서 이전 버전으로 돌아가야 할 필요성이 있는 경우,

현상 유지로 복원하거나, 오류를 수정하는 것은 불가능할 겁니다.

이러한 것이 Git에 있어 가장 중요한 개념 중 하나가 commit 인 이유입니다.

이는 프로젝트의 상태를 저장한다는 의미입니다.

당신이 매 시간 commit 할 때 마다,

시스템은 그 순간 각각의 파일이 어떻게 생겼는지 기억하고, 이 스냅샷에 대한 링크를 저장합니다.

효율성을 증가시키기 위해, 어떠한 변경 사항도 존재하지 않는다면,

Git은 다시 이러한 파일들을 기억하지 않고, 이미 저장되어 있는 이전 버전의 동일한 파일의 링크만 생성합니다.

모든 변경 사항들은 당신의 컴퓨터에 Git을 설치 한 이후로 즉시 생성 된 local db 로컬 디비에 저장됩니다.

이는 프로젝트의 기록을 거의 즉시 볼 수 있다는 것을 의미합니다.

만약 당신이 최신 버전과 한 달 전 쯤에 생성된 버전 간에 만들어진 변경 사항들을 보고 싶다면,

Git은 해당 한 달 전 쯤의 버전을 찾으며, 로컬로 변경 사항을 계산 할 수 있습니다.

Git을 검색 할 때, 이는 이전에 저장되었던 문자열을 참조합니다.

이는 Git이 어떠한 파일을 알지 못하면서 그냥 해당 파일의 내용을 가져오거나, 변경 할 수 없다는 것을 의미합니다.

이 기능은 Git에 low-level 로 내장되어 있습니다.

이런 방식으로, 정보를 전송 하고 있을 때, 정보를 잃지 않고, Git이 모르는 사이에 파일이 손상 가는 경우가 없습니다.

Conclusion - 결론

---

Git이 수행하는 주요한 것은 당신의 작업 폴더를 보관하고,

몇 가지 추가적인 정보와 함께 이를 오브젝트의 폴더에 넣는 것 입니다.

만약 당신이 Git에 익숙해 진다면, 어떤 파일을 커밋에 포함시키고, 어떤 것은 아닌지 완벽하게 통제 할 수 있습니다.

words to remember

---

internal : 내부, 본질, 내부의, 내면적인, 내국의

practical : 현실적인, 실용적인, 응용적인

typical : 전형적인, 상징적인, 정형적인

indeed : 물론, 과연, 참으로

as-is : 있는 그대로

due to : ~때문에

status quo : 현상 유지, 그대로의 상태

identical : 동일한, 똑같은

archive : 보관소