[Git] Git이란? Git의 3가지 영역과 동작 과정
들어가기
처음 Git을 접했을 때는 어렵고, 실수하면 큰일 날 것 같은 존재였다. 아마 많은 주니어 개발자들도 비슷한 고민을 해봤을 것이다.
그래서 Git을 제대로 공부해 보니, 동작 원리를 이해하는 것만으로도 생각보다 어렵지 않다는 걸 깨달았다.
나처럼 Git이 부담스럽게 느껴지는 개발자들에게 도움이 되고 싶어, Git의 개념과 기본 동작 원리를 정리해 보았다.
앗! 참고로 Git 개념을 공부하기 전에 알아두면 좋은 형상 관리 개념은 이전 포스팅에 정리했다.
Git이란?
Git은 소스 코드 관리를 위한 분산형 버전 관리 시스템(DVCS)이다.
쉽게 말해, 여러 명의 개발자가 같은 프로젝트를 각자의 컴퓨터에서 개발하고, 협업하면서 버전을 관리할 수 있도록 해주는 시스템이다.
예를 들어, 한글 파일을 작성할 때 다음과 같이 저장한 경험이 한 번쯤 있을 것이다. 😅
1. 작업물_최종.hwp
2. 작업물_최종_최종.hwp
3. 작업물_최종_최종_이미지추가.hwp
4. 작업물_최종_최종_찐최종.hwp
지금 4번 문서를 작성 중인데, 만약 3번 문서가 필요하면 다시 열어 수정해야 한다.
그런데 만약 수정이 수십 번, 수백 번 이루어진다면? 하나의 파일을 여러 명이서 동시에 작업해야 한다면? 관리하기가 점점 어려워질 것이다.
Git은 이런 문제를 체계적으로 해결해 주는 도구이다.
Git을 사용하면 파일의 변경 이력을 저장하고, 누가 언제 어떤 부분을 수정했는지 추적할 수 있다. 또한, 필요할 때 원하는 버전으로 쉽게 되돌릴 수도 있다. 여러 명의 개발자가 동시에 같은 프로젝트를 수정해야 할 때도 작업 내용을 충돌 없이 작업할 수 있도록 도와준다.
또한, Git은 단순히 변경된 부분만 저장하는 것이 아니라 특정 시점의 전체 파일 상태(스냅샷)를 저장해 둔다. 따라서 이전 버전으로 돌아가거나, 특정 시점의 변경 사항을 확인하는 것이 쉽다.
Git 3가지 영역
Git은 크게 Working Directory, Staging Area, Repository 3 영역으로 구성되어 있다.
(1) Working Directory
- 작업 중인 파일들이 저장되는 공간으로, 실제로 파일을 생성하고 수정하는 작업이 이루어진다.
- Git은 기본적으로 모든 파일을 자동으로 추적하지 않으며, 파일들은 다음과 같이 구분된다.
- 추적 대상 (Tracked Files) : Git이 변경 이력을 관리하는 파일로, git add 또는 git commit을 하면 추적 대상이 된다.
- 비추적 대상 (Untracked Files) : Git이 아직 추적하지 않는 파일로, git add를 하지 않은 파일들이 해당된다. 추적 대상이 아닌 파일들은 Git이 관리하지 않는다.
- Git은 Working Directory에서 변경 사항을 감지하지만, 비추적 대상 파일은 관리하지 않으므로 자유롭게 생성, 수정, 삭제할 수 있다.
(2) Staging Area
- Git에 커밋할 파일들이 임시로 저장되는 공간이다.
- git add 명령어를 실행하면 변경된 파일이 Staging Area에 올라가며, git commit을 하면 Staging Area에 있는 파일들만 Repository에 반영된다.
여기서 잠깐 ‼️
Staging Area 단계가 꼭 필요할까? 이 단계를 생략하고 바로 commit 하면 되는 건 아닌지 의문이 들 수 있다.
Staging Area가 없으면 모든 변경 사항을 한 번에 commit 해야 한다. 하지만 개발 중에는 여러 개의 수정이 동시에 이루어지는 경우가 많다.
예를 들어, 로그인 API를 수정하는 중에, 아이디 검증 API도 변경했다고 하자. 이 두 가지를 따로 commit 하고 싶다면, Staging Area를 이용해 필요한 변경 사항만 선택적으로 commit 할 수 있다.
(3) Repository
- Git에서 작업한 이력들이 최종적으로 저장되는 저장소이다.
- Git Repository 에서 숨겨진 파일을 확인하면 .git 이라는 파일이 존재한다. 이 .git 파일에 모든 정보(commit된 내용, branch 등)가 저장되고 관리된다.
- Repository는 Local Repository와 Remote Repository로 나뉜다.
- Local Repository (로컬 저장소) : 로컬 작업 환경에서 변경 이력을 추적하고 관리한다.
- Remote Repository (원격 저장소) : 네트워크나 인터넷에 위치한 저장소로, 여러 명이 작업할 수 있는 환경을 만들어준다.
주로 GitHub, GitLab과 같은 웹 기반 호스팅 서비스를 통해 호스팅된다.
Git 동작 과정
3가지 영역에 대해 알아봤다. 그렇다면 어떻게 3가지 영역들이 연결될까?
참고로 Git 명령어와 브랜치 전략은 다음 포스팅에서 다룰 예정이니, 여기서는 '아, 이런 명령어가 있구나!' 정도로 가볍게 이해하고 넘어가도 좋다.
1. 프로젝트를 생성한 후, `git init` 명령어를 실행하면 Git이 해당 폴더를 버전 관리 대상으로 인식하고 .git 폴더를 생성한다.
2. 로컬에서 작업한 후, `git add` 명령어를 사용해 변경된 파일을 Staging Area에 올린다.
+ `git add .`을 사용하면 모든 변경 사항을 Staging Area에 추가할 수 있다.
3. `git status` 명령어를 실행하면 Staging Area에 올라온 파일과 올라오지 않은 파일을 확인할 수 있다.
4. Staging Area에 올린 변경 사항을 확정하려면 `git commit -m "커밋 메시지"` 명령어를 실행한다. 커밋 메시지는 나중에 변경 내역을 쉽게 파악할 수 있도록 작성하는 것이 좋다.
5. 이제 로컬 저장소에 저장된 커밋을 원격 저장소(GitHub, GitLab 등)로 업로드하기 위해 `git remote add origin <URL>` 명령어로 원격 저장소를 연결한다.
+ `git remote -v`를 사용하면 연결된 원격 저장소 정보를 확인할 수 있다.
6. `git push origin main` 명령어를 사용해 로컬의 커밋을 원격 저장소의 main 브랜치로 업로드한다.
7. `git fetch` 명령어를 사용하면 Remote Repository의 최신 변경사항을 Local Repository 에 가져올 수 있다.
8. `git merge origin/main` 명령어를 사용하면 가져온 변경 사항을 현재 브랜치와 합칠 수 있다. 만약 충돌(conflict)이 발생하면 직접 수정한 후 다시 커밋해야 한다.
위 과정들만 보면 Git 사용이 복잡해 보일 수 있다. 하지만 우리에겐 IDE 라는 좋은 친구가 있다!
Git 명령어를 CLI에서 직접 입력하는 대신 IntelliJ, VS Code 등의 IDE에서 제공하는 Git 기능을 활용하면 쉽게 사용할 수 있다.
위 과정을 표로 정리했다.
| git init | Git 저장소 초기화 |
| git add <파일명> | Staging Area에 추가 |
| git status | 현재 상태 확인 |
| git commit -m "메시지" | 변경 사항을 로컬 저장소에 저장 |
| git remote add origin <URL> | 원격 저장소 연결 |
| git push origin main | 로컬 변경 사항을 원격 저장소에 반영 |
| git fetch origin | 원격 저장소 변경 사항 가져오기 |
| git merge origin/main | 가져온 변경 사항을 로컬 브랜치에 반영 |
출처
긴 글 읽어주셔서 감사합니다 🍀
잘못 작성된 내용은 피드백 주시면 반영하겠습니다 😎