Git을 모르면 취업할 수 없다고 할만큼 Git은 개발자에게 너무나 중요합니다. 지금부터 Git이 무엇이며, 왜 사용하고, 어떻게 사용할 수 있는지 Git 공식 문서와 함께 차근차근 학습해보도록 하겠습니다.
✅ Git이란?
Git은 DVCS(Distributed Version Control Systems, 분산 버전 관리 시스템)입니다. 어떤 파일의 버전을 관리할 경우, 우리는 보통 파일의 사본을 만들고 파일명 뒤에 ‘_수정’, ‘_최종본’과 같은 이름을 붙이며 기존의 파일과 새로운 버전의 파일을 구분하곤 합니다.
DVCS는 이처럼 파일에 변경 사항이 생겼을 때, 파일을 수정했던 모든 기록(버전)을 저장할 수 있는 소프트웨어 중 하나입니다. 여러 명이 함께 진행하는 프로젝트가 있을 경우 Github와 같은 원격 저장소(Remote Repository)를 통해서 팀원의 수정 사항을 저장하고 관리하며 누가, 언제, 어떤 파일을 수정했는지 모든 기록을 제공해 줍니다. 단순히 코드가 들어있는 파일뿐만 아니라 이미지, txt 파일 등도 가능하기 때문에 개발자 외에도 많은 사람들이 이 방식을 사용하고 있습니다.
위 그림에서 Server Computer은 Github가 되며, Computer A, B 각각이 개발자의 개인 PC라고 생각하면 될 것 같습니다. Server Computer을 통해 Computer A, B에서 작업했던 내용들을 모두 관리하며 공유될 수 있습니다.
🔹Git의 기초
스냅샷이란?
파일 시스템의 스냅샷(Snapshot)은 특정 시점에서 파일 시스템의 상태를 보존하고 복제하는 기술입니다. Git에서는 특정 시점을 시간보다, 각 파일의 변경 사항에 대한 시점을 확인합니다. 쉽게 이야기하면 ‘언제’ 변했는지를 체크하는 것이 아니라, ‘무엇이’ 변했는지에 따라 파일이 변경되었다고 파악합니다. 이러한 스냅샷은 파일 시스템의 데이터 무결성, 복원, 백업 등을 지원하는 중요한 도구로 사용됩니다.
스냅샷은 파일 시스템의 현재 상태를 정적으로 캡처하여 이전 상태로 롤백하거나 복원하는 데 사용될 수 있습니다. 스냅샷은 주로 변경 데이터의 복사본을 만들어 다른 시점의 파일 시스템 상태를 표시합니다. 이러한 스냅샷은 원본 파일 시스템과는 독립적으로 관리되며, 변경된 데이터만 저장되므로 공간 효율성을 제공합니다.
스냅샷은 일반적으로 저장 장치의 블록 레벨을 기반으로 작동합니다. 파일 시스템은 블록 단위로 데이터를 저장하고 스냅샷은 변경된 블록만 따로 저장하여 이전 상태를 재현합니다. 따라서 스냅샷은 파일이나 디렉토리 수준이 아닌 블록 수준에서 작동하며, 파일 시스템의 전체 상태를 보존합니다.
➡️ 스냅샷은 다음과 같은 몇 가지 주요 용도로 활용됩니다:
- 데이터 복원: 스냅샷은 파일 시스템의 이전 상태로 복원할 수 있으므로 데이터 손실이 발생한 경우에 유용합니다. 스냅샷을 사용하여 이전 상태로 롤백하거나 삭제된 파일을 복구할 수 있습니다.
- 백업: 스냅샷은 파일 시스템의 상태를 안정적으로 보존하는 데 사용됩니다. 스냅샷은 데이터를 복사하는 데 필요한 시간과 공간을 최소화하면서 백업을 만들어줍니다. 또한 스냅샷은 백업된 상태에서도 파일에 대한 읽기 작업을 지원하므로 데이터 복원이 필요한 경우 빠른 액세스가 가능합니다.
- 테스트 및 개발: 스냅샷은 개발자가 파일 시스템의 특정 시점에서 작업한 결과를 보존하고 다양한 테스트를 수행하는 데 도움을 줍니다. 스냅샷을 사용하면 개발자는 실험적인 변경 사항을 안전하게 테스트할 수 있고, 문제가 발생한 경우 스냅샷을 사용하여 이전 상태로 복원할 수 있습니다.
스냅샷은 다양한 운영 체제와 파일 시스템에서 지원되며, 각각의 시스템에서는 스냅샷을 만들고 관리하기 위한 특정 명령 및 도구를 제공합니다.
🔹 Git은 어떻게 파일을 관리하는가?
앞에서 Git은 파일의 ‘무엇이’ 변했는지에 대해서 시점으로 기록한다고 하였습니다. Git과 다른 프로그램들에서는 보통 파일의 ‘시점’이 변했는지에 대해서 기록합니다. 무엇이 다른지 자세하게 살펴보겠습니다.
각 파일을 시간 순으로 저장
Git과 다른 버전 관리 프로그램의 가장 큰 차이점은 데이터를 다루는 방법에 있습니다. 큰 틀에서 봤을 때 VCS 시스템 대부분은 관리하는 정보가 파일들의 목록입니다. CVS, Subversion, Perforce, Bazaar 등의 시스템은 각 파일의 변화를 시간순으로 관리하면서 파일들의 집합을 관리합니다. (보통 델타 기반 버전관리 시스템이라 함).
각 파일의 상태 변화를 체크해서 저장
Git은 특정 시간을 가지고 데이터를 저장하지도 취급하지도 않습니다. 대신 Git은 데이터를 파일 시스템 스냅샷의 연속으로 취급하여 크기가 매우 작습니다. Git은 커밋하거나 프로젝트의 상태를 저장할 때마다 파일이 존재하는 그 순간을 중요하게 여기기 때문에 파일이 달라지지 않았으면 Git은 성능을 위해서 파일을 새로 저장하지 않습니다. 단지 이전 상태의 파일에 대한 링크만 저장합니다. Git은 데이터를 스냅샷의 스트림처럼 취급하여 상태의 변화를 체크하여 저장하는 시스템입니다.
🔹Git의 장점
이러한 Git을 사용하는 장점은 아래와 같습니다.
거의 모든 명령을 로컬에서 실행하며 속도가 매우 빠르다.
거의 모든 명령을 로컬 파일과 데이터로만 사용하기 때문에 다른 네트워크에 있는 컴퓨터는 필요가 없습니다. 프로젝트의 모든 히스토리가 로컬 디스크에서 관리됩니다. 예를 들어 Git은 프로젝트의 히스토리(이력)을 조회할 때 서버 없이 로컬 디스크에 있는 이력을 조회합니다. 어떤 파일의 현재 버전과 한 달 전의 상태를 비교해보고 싶을 때도 Git은 한 달 전의 파일과 지금의 파일의 히스토리를 비교하기 위해서 로컬에서 조회합니다. 즉, 상태를 체크하는 것은 리모트와의 동기화가 필요하지 않고 ‘로컬의 데이터’로만 동작합니다.
그렇기 때문에 오프라인 상태, VPN에 연결하지 못해도 커밋할 수 있으며, 이는 다른 VCS 시스템에서는 불가능한 일입니다. Subversion이나 CVS에서도 마찬가지며, 오프라인이기 때문에 데이터베이스에 접근할 수 없어서 파일을 편집할 수는 있지만, 커밋할 수 없습니다.
Git의 무결성
Git은 파일의 무결성을 위해서 SHA-1 해시 방식으로 체크섬 값을 만듭니다. Git은 데이터를 저장하기 전에 항상 체크섬을 구하고, 그 체크섬으로 데이터를 관리합니다. 만든 체크섬은 40자 길이의 16진수 문자열이며, 파일의 내용이나 디렉토리 구조를 이용하여 구하고 아래와 같이 생겼습니다.
24b9da6552252987aa493b52f8696cd6d3b00373
Git은 모든 것을 해시로 식별하기 때문에 이런 값은 여기저기서 보일 겁니다. 실제로 Git은 파일을 이름으로 저장하지 않고 해당 파일의 해시로 저장합니다. 이를 통해 파일의 최신 상태를 확인하며, 체크섬은 Git에서 사용하는 가장 기본적인(Atomic) 데이터 단위이자 Git의 기본 철학입니다. 이러한 방식을 통해 파일의 변경 사항이 충돌되지 않는 무결성을 유지시킬 수 있습니다.
Git은 데이터를 추가할 뿐이며, 모든 사항을 기록한다.
Git으로 무얼 하든 Git 데이터베이스에 데이터가 추가됩니다. 되돌리거나 데이터를 삭제할 방법이 없습니다. 다른 VCS처럼 Git도 커밋하지 않으면 변경사항을 잃어버릴 수 있지만, 일단 스냅샷을 커밋하고 나면 데이터를 잃어버리기 어렵습니다.
✅ Git의 세가지 상태 ‼️
이 부분은 중요하기에 집중해서 읽어야 합니다. Git을 공부하기 위해 반드시 짚고 넘어가야 할 부분이며, Git은 파일을 Committed, Modified, Staged 이렇게 세 가지 상태로 관리합니다.
| Committed | 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미한다 |
|---|---|
| Modified | 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않은 것을 말한다 |
| Staged | 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태를 의미한다 |
이 세 가지 상태는 Git 프로젝트의 세 가지 단계[Working, Tree, Index, Repository]와 연결되어 있습니다.
Git의 작업 디렉토리에는 추적되지 않는(untracked) 파일과 추적된(tracked) 파일이 혼재해 있습니다. 이는 뒤에서 더 자세하게 다뤄보겠습니다.
- Working Directory
개발자의 작업 공간입니다. 개발자가 작성한 코드들이 저장되는 장소를 의미합니다. 흔히 로컬 PC라고 이야기할 수 있습니다.
- Index, Staging Area
Staging Area는 엄밀히 따지자면 Git 디렉토리(.git 폴더) 안에 있습니다. 곧 커밋할 파일에 대한 정보를 저장합니다. Git에서는 기술용어로는 “Index” 라고 하지만, “Staging Area” 라는 용어를 쓰기도 합니다.
- Git 디렉토리
Git 디렉토리는 Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳을 말합니다. 이 Git 디렉토리가 Git의 핵심이다. 다른 컴퓨터에 있는 저장소를 Clone 할 때 Git 디렉토리가 만들어집니다. 워킹 트리는 프로젝트의 특정 버전을 Checkout 한 것입니다. Git 디렉토리는 지금 작업하는 디스크에 있고 그 디렉토리 안에 압축된 데이터베이스에서 파일을 가져와서 워킹 트리를 만듭니다.
➡️ Git으로 하는 일은 기본적으로 아래와 같습니다.
- 개발자가 워킹 트리에서 파일을 수정합니다.
- Staging Area에 파일을 Staged 해서 커밋할 스냅샷을 만듭니다. 모든 파일을 추가할 수도 있고 선택하여 추가할 수도 있습니다.
- Staging Area에 있는 파일들을 커밋해서 Git 디렉토리에 영구적인 스냅샷으로 저장합니다.
Git 디렉토리에 있는 파일들은 Committed 상태입니다. 파일을 수정하고 Staging Area에 추가했다면 Staged입니다. 그리고 Checkout 하고 나서 수정했지만, 아직 Staging Area에 추가하지 않았으면 Modified입니다. 이는 뒤에 Git의 기초에서 이 상태에 대해 좀 더 자세히 배우게 될 것입니다.
🔹 Index 필요성
Git의 '커밋' 작업은 '워킹 트리'에 있는 변경 내용을 저장소에 바로 기록하는 것이 아니라 그 사이 공간인 '인덱스'에 파일 상태를 기록(stage - 스테이징 한다고 표현하기도 합니다)하게 되어 있습니다. 따라서 저장소에 변경 사항을 기록하기 위해서는, 기록하고자 하는 모든 변경 사항들이 '인덱스'에 존재해야 합니다.
예를 들어, 10개의 파일을 수정했지만 그 중에 7개만 저장소에 공개하고 싶을 때를 생각해 보세요. 변경한 10개의 파일 중 7개를 선택하는 작업이 바로 '인덱스에 등록' 또는 '스테이징(stage)'이라 표현하는 작업 입니다.
이렇게 인덱스란 가상 공간이 중간에 있는 덕분에 워킹 트리안에 있는 커밋이 필요 없는 파일들을 커밋에 포함하지 않을 수 있고, 파일에서 내가 원하는 일부 변경 사항만 인덱스에 등록해 커밋할 수 있습니다.
✅ Git 설치 -Windows
👉 이후 설치는 전부 기본 설정으로 설치하였습니다.
✅ Git 최초 설정
Git을 설치하고 나면 Git의 사용 환경을 적절하게 설정해 주어야 합니다. 환경 설정은 한 컴퓨터에서 한 번만 하면 되고, 설정한 내용은 Git을 업그레이드해도 유지됩니다.
- 사용자 정보
git config --global user.name "John Doe" git config --global user.email johndoe@example.comGit을 설치하고 나서 가장 먼저 해야 하는 것은 사용자이름과 이메일 주소를 설정하는 것입니다. Git은 커밋할 때마다 이 정보를 사용하고, 한 번 커밋한 후에는 정보를 변경할 수 없습니다. 다시 말하자면
--global옵션으로 설정하는 것은 딱 한 번만 하면 됩니다.
- 편집기
#64bit $ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -nosession" #32bit $ git config --global core.editor "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -nosession"사용자 정보를 설정하고 나면 Git에서 사용할 텍스트 편집기를 고를 수 있습니다. 기본적으로 Git은 시스템의 기본 편집기를 사용합니다. Windows에서 가장 많은 텍스트 편집기로 사용하는 Notepad++로 기본 에디터를 설정합니다. 설정할 때 본인이 설치한 Notepad++.exe 경로를 제대로 설정해야 합니다. notepad++의 명령어로만 설정할 경우, 제대로 동작하지 않는 이유가 해당 경로를 찾지 못하기 때문입니다.
❗git editor notepad++ 설정이 안됨 → notepad++.exe의 경로 확인- jhcode33
git config --global core.editor "'C:\DevProgram\notepad\notepad++.exe' -multiInst -nosession"
- jhcode33
🏷️이미지 출처 및 참고한 사이트
Uploaded by N2T