Git을 제대로 쓰는 방법: 구조부터 사용법까지 한 번에 정리

개발 테크

3시간 전

조회수

Git은 개발 환경에서 가장 널리 쓰이는 도구 중 하나입니다. 하지만 많은 경우 ‘코드를 저장하는 도구’ 정도로만 이해됩니다.

Git은 코드의 현재 상태가 아니라, 변경의 흐름을 관리합니다. 파일이 어떻게 바뀌었는지를 기록하기 때문에, 되돌릴 수도 있고, 비교할 수도 있고, 여러 사람이 동시에 작업할 수도 있습니다.

이 글에서는 Git을 기능 나열이 아니라, 실제 사용 맥락 속에서 정리합니다. 개발 과정에서 Git이 어떤 역할을 하는지부터 살펴보겠습니다.

Git이란?

Git은 버전 관리 시스템입니다. 파일이 어떻게 바뀌었는지를 시간 순서대로 기록하고, 필요하면 이전 상태로 되돌릴 수 있도록 관리하는 도구입니다. Git은 변경된 시점과 변경된 내용을 자동으로 기록해 매번 파일을 복사해서 따로 저장하거나, 날짜를 붙여 관리하지 않아도 됩니다.

개발 과정에서 코드는 계속 수정됩니다. 기능이 추가되기도 하고, 기존 코드가 바뀌기도 하며, 때로는 삭제되기도 합니다. 이 과정에서 누가 어떤 부분을 바꿨는지 알 수 없으면, 문제가 생겼을 때 원인을 찾기 어렵습니다. Git은 이런 문제를 해결하기 위해 만들어졌습니다.

Git은 모든 변경을 기록하고, 그 흐름을 추적할 수 있도록 설계되었습니다. 특정 시점의 상태를 확인할 수 있고, 필요하면 이전 상태로 되돌릴 수도 있습니다. 여러 사람이 동시에 작업하더라도, 각자의 변경 내용을 관리하고 병합할 수 있습니다. 이 구조 덕분에 Git은 개인 개발뿐만 아니라, 협업 환경에서도 널리 사용됩니다.

Git의 동작 구조

Git은 단순히 파일을 저장하는 도구가 아닙니다. 내부적으로는 데이터를 객체(object) 단위로 관리하고, 이 객체들을 그래프 구조로 연결해 변경 이력을 유지합니다.

이 구조 덕분에 Git은 빠르고, 가볍고, 되돌리기가 쉬운 시스템으로 동작합니다.

1. Git은 객체(Object) 기반으로 데이터를 저장합니다

Git은 모든 데이터를 객체로 저장합니다. 이 객체들은 .git/objects 디렉터리 안에 보관되며, 각각의 역할이 명확하게 구분되어 있습니다.

Git의 기본 객체 4가지

Blob: 파일의 내용 자체를 저장합니다
Tree: 디렉터리 구조를 저장합니다 (어떤 파일이 어떤 폴더에 있는지)
Commit: 특정 시점의 전체 상태를 가리키는 객체입니다 (작성자, 시간, 메시지, 부모 커밋 정보 포함)
Tag: 특정 커밋에 이름을 붙이는 객체입니다

이 객체 구조가 Git 저장 방식의 핵심입니다.

2. Git은 스냅샷(Snapshot) 방식으로 동작합니다

Git은 변경된 부분만 저장하는 시스템이 아닙니다. 각 커밋마다 프로젝트 전체 상태를 하나의 스냅샷으로 기록합니다.

다만 실제로는 바뀌지 않은 파일은 이전 객체를 재사용하고, 바뀐 부분만 새 객체로 저장합니다. 그래서 저장 속도가 빠르, 중복 저장이 없으며, 특정 시점으로 되돌리기가 쉽습니다

3. Git의 커밋은 그래프(DAG) 구조로 연결됩니다

Git의 커밋들은 단순한 목록이 아닙니다. 서로를 가리키는 그래프 구조(DAG, Directed Acyclic Graph)로 연결됩니다.

이 구조의 특징

각 커밋은 이전 커밋을 가리킵니다
순환이 없습니다 (한 방향으로만 흐릅니다)
여러 갈래로 분기할 수 있습니다

이 구조 덕분에:

브랜치가 가능하고
병합이 가능하며
히스토리를 추적할 수 있습니다

4. 브랜치는 포인터(Reference)입니다

브랜치는 특정 커밋을 가리키는 참조(reference)입니다.

같은 방식으로:

HEAD는 현재 위치를 가리키는 참조입니다
Tag는 특정 커밋에 붙는 고정된 이름입니다

이 구조 덕분에 Git의 브랜치는 매우 가볍고, 빠르게 생성·이동할 수 있습니다.

5. Git에는 중간 단계(Index)가 있습니다

Git에는 작업 디렉터리와 커밋 사이에 Index(Staging Area)라는 중간 단계가 존재합니다.

흐름은 다음과 같습니다

작업 디렉터리 (Working Directory)

↓ git add

Index (Staging Area)

↓ git commit

로컬 저장소 (Local Repository)

↓ git push

원격 저장소 (Remote Repository)

이 구조가 있기 때문에:

커밋할 변경을 선택적으로 골라낼 수 있고
작업 중인 파일과 기록할 파일을 구분할 수 있으며
커밋 단위를 정리할 수 있습니다

6. Git은 해시(SHA-1)로 모든 것을 식별합니다

Git의 모든 객체는 SHA-1 해시값으로 식별됩니다. 파일 내용이 조금이라도 바뀌면 완전히 다른 해시값이 생성됩니다.

예시:

a3f5b2c... → 'hello' 파일

d8e9a1b... → ‘hello world’ 파일

이 방식 덕분에:

같은 내용은 한 번만 저장됩니다 (중복 제거)
데이터 무결성이 보장됩니다 (변조 감지)
특정 시점을 정확히 참조할 수 있습니다

Git이 동작하는 흐름

Git은 파일을 저장하는 방식으로 동작하지 않습니다. 대신, 파일이 어떻게 바뀌었는지를 중심으로 움직입니다.

어떤 파일이 추가되었는지, 어떤 부분이 수정되었는지, 무엇이 삭제되었는지를 기준으로 기록합니다. 이 구조 때문에 Git은 단순한 저장 도구가 아니라, 변경의 흐름을 관리하는 시스템으로 동작합니다.

변경을 감지합니다

Git은 파일이 바뀌었는지를 항상 확인합니다. 사용자가 코드를 수정하면, Git은 이전 상태와 현재 상태를 비교합니다. 그리고 어떤 부분이 달라졌는지를 파악합니다.

새로운 파일이 추가되었는지
기존 파일이 수정되었는지
파일이 삭제되었는지

이 단계에서는 아직 기록이 남지 않습니다. Git은 단지 ‘무언가 바뀌었다’는 사실만 인식합니다.

기록할 대상을 구분합니다

Git은 사용자가 어떤 변경을 기록할지 선택하도록 설계되어 있습니다. 이 구조 덕분에, 의미 없는 변경과 의미 있는 변경을 구분할 수 있습니다.

지금 작업 중인 변경
나중에 정리할 변경
아직 실험 중인 변경

이렇게 변경을 나누는 것이 가능합니다. 이 과정은 기록의 단위를 만들기 위한 준비 단계입니다.

하나의 시점으로 묶어 기록합니다

Git은 변경 내용을 하나의 시점으로 묶어 저장합니다. 이 시점이 바로 ‘커밋’입니다. 커밋은 단순한 저장이 아니라, ‘이 순간의 상태’를 남기는 기록입니다.

어떤 파일이 바뀌었는지
누가 작업했는지
언제 기록했는지

이 정보가 함께 저장됩니다. 커밋이 쌓이면, 프로젝트의 변화 과정이 시간 순서대로 정리됩니다.

기록을 연결해 흐름을 만듭니다

Git의 모든 기록은 서로 연결되어 있습니다. 각각의 커밋은 이전 커밋을 가리킵니다. 이 구조 덕분에, Git은 변경의 ‘점’이 아니라 ‘흐름’을 만듭니다.

이전 상태를 추적할 수 있습니다.
특정 시점으로 돌아갈 수 있습니다.
변경 과정을 한눈에 볼 수 있습니다.

이 연결 구조가 Git의 핵심입니다.

여러 흐름을 동시에 관리합니다

Git은 여러 개의 작업 흐름을 동시에 유지할 수 있도록 설계되어 있습니다. 이 구조가 바로 ‘브랜치’입니다.

기존 작업과 분리된 흐름을 만들 수 있습니다.
실험적인 작업을 따로 진행할 수 있습니다.
문제가 생겨도 원래 흐름에는 영향을 주지 않습니다.

이 덕분에, 여러 사람이 동시에 작업하는 것이 가능합니다.

흐름을 다시 하나로 합칩니다

Git은 서로 다른 변경을 비교하고, 하나의 흐름으로 정리합니다. 분리된 작업을 하나로 합쳐 서로 다른 작업을 하나로 모읍니다.

같은 파일을 수정했다면 충돌이 발생합니다.
충돌은 사용자가 직접 해결합니다.

Git이 복잡하게 느껴지는 이유 중 하나가 이 단계입니다. 하지만 구조를 이해하면, 왜 이런 과정이 필요한지도 자연스럽게 이해됩니다.

Git은 이러한 구조를 활용해, 코드를 실수한 지점으로 되돌리거나 변경 내용을 비교하고, 누가 무엇을 수정했는지를 확인하며 팀 안에서의 작업을 정리합니다.

Git 사용법

Git 사용은 일정한 흐름을 반복합니다. 먼저 변경을 확인하고, 기록할 변경을 고른 뒤, 커밋으로 남깁니다. 협업한다면 원격 저장소와 동기화하면 됩니다.

1) 저장소를 준비합니다

새 프로젝트를 Git으로 관리하려면 저장소를 생성합니다. 이미 있는 프로젝트라면 원격 저장소를 복제하면 됩니다.

새 프로젝트를 시작할 때

basbashh

git init

기존 프로젝트를 가져올 때

bash

git clone <원격_저장소_URL>

이 단계가 끝나면 Git이 해당 폴더의 변경을 추적하기 시작합니다.

2) 현재 상태를 확인합니다

작업을 시작하기 전에 상태를 확인하는 습관이 중요합니다. 어떤 파일이 바뀌었는지 먼저 보면 실수를 줄일 수 있습니다.

bash

git status

이 명령은 다음을 보여줍니다.

수정된 파일이 무엇인지
새로 추가된 파일이 있는지
다음에 무엇을 해야 하는지 힌트까지

3) 기록할 변경을 선택합니다

Git은 변경을 자동으로 기록하지 않아 기록할 파일을 직접 선택해야 합니다. 이 단계가 ‘기록 단위를 정리하는 과정’입니다.

특정 파일만 선택할 때

bash

git add <파일명>

변경된 파일을 한 번에 선택할 때

bash

git gidd .

이 시점부터 선택한 파일은 "기록할 준비가 된 변경"으로 분류됩니다.

4) 커밋으로 기록을 남깁니다

선택한 변경을 하나의 작업 단위로 묶어 기록합니다. 커밋 메시지는 나중에 작업 내용을 구분하는 기준이 됩니다.

bash

git commit -m "메시지"

커밋은 '저장'과 비슷하지만, 단순 저장이 아닙니다.

작업 단위를 남기는 기록입니다
나중에 비교와 되돌리기의 기준점이 됩니다

5) 원격 저장소와 연결합니다

원격 저장소가 없다면 먼저 연결해야 합니다. git clone으로 가져왔다면 보통 연결이 되어 있습니다.

원격 저장소 확인

bash

git remote -v

원격 저장소 추가

bash

git remote add origin <원격_저장소_URL>

원격 저장소는 협업을 위한 ‘공유 공간’입니다.

6) 변경을 공유합니다

로컬에서 만든 커밋을 원격 저장소로 전송합니다. 팀 작업에서는 이 과정이 필수입니다.

bash

git push origin <브랜치명>

처음 push 하는 경우에는 upstream 설정을 함께 쓰는 경우가 많습니다.

bash

git push -u origin <브랜치명>

이렇게 하면:

다른 사람이 내 변경을 받을 수 있습니다
원격 저장소에 기록이 남습니다

7) 다른 사람의 변경을 가져옵니다

협업에서는 내 변경만큼 남의 변경도 중요합니다. 작업 전후로 원격 변경을 가져오는 습관이 필요합니다.

원격 변경을 가져와서 병합까지 한 번에 (자주 사용)

bash

git pull origin <브랜치명>

가져오기만 하고, 나중에 합칠 때

bash

git fetch origin

pull은 편하지만, 상황에 따라 충돌이 발생할 수 있습니다.

8) 브랜치를 만들고 합칩니다

브랜치는 작업을 분리하기 위한 기본 단위입니다. 기능 개발이나 수정 작업을 분리해서 진행할 때 씁니다.

브랜치 목록 확인

bash

git branch

브랜치 생성

bash

git branch <브랜치명>

브랜치 이동

bash

git switch <브랜치명>

(또는)

bash

git checkout <브랜치명>

브랜치 생성+이동을 한 번에

bash

git switch -c <브랜치명>

작업이 끝나면 병합합니다.

bash

git merge <브랜치명>

충돌(Conflict)이 발생하는 경우

같은 파일의 같은 부분을 서로 다르게 수정하면 충돌이 납니다. 충돌은 Git이 자동으로 판단하지 못하는 구간이라, 사람이 직접 선택해서 정리해야 합니다.

9) 자주 쓰는 확인 명령

기록을 남기고 나면 확인이 필요합니다. 실무에서는 아래 명령을 가장 많이 사용합니다.

커밋 로그 확인

bash

git log

변경 내용 비교

bash

git diff

한 줄로 간단히 로그 보기

bash

git log --oneline

Git 사용 흐름 요약

실무에서 가장 흔한 흐름은 아래 형태로 반복됩니다.

git status로 상태를 확인합니다
git add로 기록할 변경을 고릅니다
git commit으로 작업 단위를 남깁니다
git pull로 최신 변경을 가져옵니다
git push로 변경을 공유합니다

이 흐름이 잡히면 Git은 훨씬 단순해집니다.

Git과 GitHub의 차이

Git과 GitHub는 자주 함께 언급되지만, 서로 다른 개념입니다. Git은 버전 관리 시스템이고, GitHub는 그 Git 저장소를 온라인에서 관리할 수 있도록 제공하는 서비스입니다. 즉, Git은 도구이고, GitHub는 플랫폼입니다.

▶ 깃 허브 사용법, 현직 개발자가 알려주는 깃과 깃허브 사용법 보러가기

Git은 로컬 환경에서도 사용할 수 있습니다. 인터넷 연결이 없어도 변경 이력을 기록하고, 이전 상태로 되돌릴 수 있습니다. 모든 기록은 개인 컴퓨터 안에 저장됩니다. 이 상태에서도 Git의 핵심 기능은 모두 사용할 수 있습니다.

반면 GitHub는 Git 저장소를 서버에 올려 관리할 수 있게 해줍니다. 여러 사람이 같은 저장소에 접근할 수 있고, 변경 내용을 공유할 수 있습니다. 협업이 필요한 환경에서는 이런 원격 저장소가 필수적입니다.

Git이 담당하는 역할

Git은 변경의 기록과 흐름을 관리합니다. 파일이 어떻게 바뀌었는지를 중심으로 데이터를 저장하고, 이전 상태와의 관계를 유지합니다.

변경 이력 기록
이전 상태로 되돌리기
브랜치 관리
병합 처리

이 기능들은 모두 Git 자체의 기능입니다. GitHub가 없어도 사용할 수 있습니다.

GitHub가 담당하는 역할

GitHub는 Git 저장소를 원격으로 보관하고, 여러 사람이 함께 사용할 수 있도록 돕는 서비스입니다. 코드 관리뿐만 아니라, 협업에 필요한 다양한 기능을 함께 제공합니다.

원격 저장소 제공
변경 내용 공유
코드 리뷰
이슈 관리
프로젝트 관리

GitHub는 Git의 기능을 확장하는 역할을 합니다.

함께 참고하면 좋은 콘텐츠

깃 허브 사용법, 현직 개발자가 깃과 깃허브 사용법을 알려드립니다.

웹 서버와 WAS, 무엇이 다를까? 차이부터 활용 방법까지 한 번에 정리

REST API 설계가 흔들릴 때 나타나는 신호들

Git과 GitHub를 실제 프로젝트 운영에

맞게 활용할 수 있는 개발자가 필요하다면

Git과 GitHub를 단순히 ‘사용할 줄 아는 것’과, ‘운영할 줄 아는 것’은 다릅니다. 브랜치 전략을 설계하고, 협업 흐름을 정리하며, 충돌을 최소화하고, 변경 기록을 자산으로 남길 수 있는 개발자가 있어야 프로젝트는 안정적으로 운영됩니다.

이랜서는 Git과 GitHub를 실제 프로젝트 운영에 맞게 활용할 수 있는 개발자가 필요할 때, 실무 경험을 갖춘 IT 프리랜서를 빠르게 매칭합니다.

개발자, 디자이너, 기획자, 퍼블리셔, 데이터 엔지니어, 시스템 엔지니어 등 전 분야 전문가 매칭
프로젝트 등록 시 약 41만 명의 IT 전문 프리랜서에게 자연스럽게 노출
요구사항에 맞는 인력의 지원을 받아 정밀 매칭 가능
계약 및 협업 과정을 안정적으로 지원

도구를 도입하는 것보다 중요한 것은, 그 도구를 제대로 다룰 수 있는 사람입니다.
Git과 GitHub를 실제 프로젝트 운영에 맞게 활용할 수 있는 개발자가 필요하다면, 이랜서에 프로젝트를 등록하고 Git과 GitHub 전문 개발자의 지원을 받아보세요.

FAQ

Git은 자동으로 변경 내용을 저장해 주는 도구인가요?

Git에서 되돌리면 기록이 사라지나요?

Git과 GitHub는 같은 도구인가요?

이랜서에 로그인하고 댓글을 남겨보세요!

0자

/200자

이랜서에 로그인하고 댓글을 남겨보세요!

0자

/200자

실시간 인기 게시물

이랜서 PICK 추천 게시물