프로젝트를 진행하다 보면 “어제 작업한 버전으로 되돌리고 싶다”, “팀원이 수정한 코드와 내 코드를 합쳐야 한다”, “이 파일을 대체 누가 언제 바꿨지?” 같은 상황을 반드시 만나게 됩니다. 이런 문제를 한 방에 해결해 주는 도구가 바로 Git입니다.

Git은 2005년 리누스 토르발스가 리눅스 커널 개발을 위해 만든 분산 버전 관리 시스템입니다. 20년이 넘은 지금까지도 전 세계 개발자의 사실상 표준 도구로 자리 잡고 있으며, 2026년 현재 GitHub에 등록된 공개 저장소는 5억 개를 돌파했습니다. 이제 Git은 개발자만의 도구가 아닙니다. 디자이너, 기술 작가, 데이터 분석가까지 — 파일의 변경 이력을 안전하게 관리해야 하는 곳이라면 어디든 Git이 쓰이고 있고, 구인 공고에서 “Git 사용 가능”은 거의 기본 요구 사항이 되었습니다.

이 글에서는 Git을 처음 접하는 분부터 팀 협업에 본격적으로 활용하려는 분까지, 설치와 초기 설정, 핵심 명령어, 브랜치와 머지, 원격 저장소 연동, 실수 복구, PR 기반 팀 워크플로우를 한 편에 총정리합니다. 터미널이 낯설어도 괜찮습니다. 하나씩 따라 하다 보면 자연스럽게 손에 익게 됩니다.

Git 설치와 초기 설정

운영 체제별 설치 방법

Windows에서는 Git for Windows를 설치하는 것이 가장 간편합니다. 공식 사이트(git-scm.com)에서 설치 파일을 다운로드하거나, 터미널 패키지 매니저를 쓰고 계신다면 한 줄이면 됩니다.

• winget: winget install Git.Git
• scoop: scoop install git

설치가 끝나면 PowerShell이나 Windows Terminal을 열고 git --version을 입력합니다. 버전 번호가 출력되면 설치 완료입니다.

macOS는 터미널에서 git을 입력하면 Xcode Command Line Tools 설치를 자동으로 안내합니다. Homebrew를 사용한다면 brew install git으로 최신 버전을 받을 수 있습니다. Linux는 배포판의 패키지 매니저를 사용합니다. Ubuntu/Debian 계열은 sudo apt install git, Fedora는 sudo dnf install git입니다.

필수 초기 설정 — git config

Git을 설치한 직후 반드시 해야 할 설정이 두 가지 있습니다. 사용자 이름과 이메일입니다. 이 정보는 여러분이 만드는 모든 커밋에 서명처럼 기록됩니다.

• git config --global user.name "홍길동"
• git config --global user.email "[email protected]"

커밋 메시지를 작성할 때 사용할 에디터도 설정해 두면 편합니다. VS Code를 기본 에디터로 쓰려면 다음 명령을 입력합니다.

• git config --global core.editor "code --wait"

설정이 잘 적용됐는지 확인하려면 git config --list를 실행합니다. 위에서 지정한 이름, 이메일, 에디터가 목록에 나타나면 준비 완료입니다.

Windows 사용자 팁: 줄바꿈 자동 변환으로 인한 혼란을 방지하기 위해 git config --global core.autocrlf true를 설정해 두세요. macOS/Linux에서는 input으로 지정합니다. 이렇게 하면 OS 간 협업 시 줄바꿈 문자 때문에 불필요한 변경이 감지되는 문제를 막을 수 있습니다.

Git의 세 가지 영역 이해하기

Git 명령어를 제대로 쓰려면 먼저 Git이 파일을 관리하는 세 가지 영역을 이해해야 합니다. 이 개념만 잡으면 add, commit, reset 같은 명령어가 왜 그렇게 동작하는지 자연스럽게 이해됩니다.

• Working Directory(작업 디렉토리): 여러분이 실제로 파일을 편집하는 공간입니다. 아직 Git이 추적하지 않는 변경 사항이 여기에 있습니다.
• Staging Area(스테이징 영역, Index): git add로 “이번 커밋에 포함시킬 변경”을 선별해 놓는 대기 공간입니다.
• Repository(저장소): git commit으로 확정된 스냅샷이 영구 보관되는 곳입니다. 프로젝트 폴더 안의 .git 숨김 폴더에 전체 히스토리가 저장됩니다.

비유하자면, 작업 디렉토리는 작업대, 스테이징 영역은 택배 포장대, 저장소는 창고입니다. 작업대에서 물건을 만들고, 포장대에서 보낼 것만 골라 상자에 넣은 다음, 창고에 넣어 영구 보관하는 흐름입니다. 이 세 단계의 흐름을 머릿속에 그릴 수 있으면 Git의 절반은 이해한 셈입니다.

핵심 명령어 기초편 — 매일 쓰는 7가지

1. git init — 새 저장소 만들기

빈 폴더에서 Git 버전 관리를 시작하려면 git init을 입력합니다. 이 명령은 현재 폴더에 .git이라는 숨김 폴더를 생성하고 Git 저장소로 초기화합니다. 기존에 파일이 있는 프로젝트에 Git을 도입할 때도 해당 폴더로 이동한 뒤 git init만 실행하면 됩니다.

2. git clone — 기존 저장소 복제하기

GitHub이나 GitLab에 이미 있는 프로젝트를 내 컴퓨터로 가져오려면 git clone을 사용합니다.

• git clone https://github.com/사용자명/저장소명.git

clone은 원격 저장소의 모든 파일은 물론 전체 커밋 히스토리까지 한 번에 내려받습니다. 네트워크가 끊어져도 로컬에서 과거 기록을 자유롭게 조회할 수 있는 것이 중앙 집중 방식과 다른 Git의 큰 장점입니다.

3. git status — 현재 상태 한눈에 보기

git status는 Git을 쓰면서 가장 자주 입력하게 될 명령어입니다. 어떤 파일이 수정됐는지, 스테이징 영역에 올라갔는지, 아직 추적되지 않는 새 파일은 무엇인지 한눈에 보여 줍니다. 습관적으로 git status를 먼저 확인한 뒤 add와 commit을 진행하면 실수를 크게 줄일 수 있습니다.

4. git add — 변경 사항을 스테이징에 올리기

파일을 수정한 뒤 커밋에 포함시키려면 먼저 스테이징 영역에 올려야 합니다.

• git add 파일명 — 특정 파일만 스테이징
• git add . — 현재 디렉토리의 모든 변경 파일을 한꺼번에 스테이징
• git add -p — 파일 안의 변경 사항을 덩어리(hunk)별로 확인하며 선택적으로 스테이징 (고급 사용자 추천)

팁: git add .은 편리하지만, 로그 파일이나 빌드 산출물처럼 저장소에 넣으면 안 되는 파일까지 포함할 수 있습니다. 이 문제는 뒤에서 다룰 .gitignore로 깔끔하게 해결됩니다.

5. git commit — 변경 사항을 영구 기록으로 남기기

스테이징에 올린 변경을 확정하는 명령이 git commit입니다.

• git commit -m "로그인 폼 유효성 검사 추가"

커밋 메시지는 “무엇을 왜 변경했는지”를 간결하게 적는 것이 좋습니다. “수정”, “업데이트”같은 모호한 한 단어는 나중에 히스토리를 추적할 때 전혀 도움이 되지 않습니다.

좋은 커밋 메시지의 패턴으로 Conventional Commits가 있습니다. 접두어로 변경의 성격을 표시하는 방식입니다.

• feat: 사용자 프로필 이미지 업로드 기능 추가
• fix: 장바구니 수량 0 이하 입력 시 오류 수정
• docs: README에 설치 가이드 보강
• refactor: 결제 로직 함수 분리

혼자 할 때도 이 습관을 들여 두면 팀 프로젝트에 바로 적응할 수 있습니다.

6. git log — 커밋 히스토리 조회하기

지금까지 쌓인 커밋 기록을 보려면 git log를 사용합니다.

• git log — 전체 히스토리를 상세하게 표시
• git log --oneline — 한 줄 요약 (가장 실용적)
• git log --oneline --graph --all — 모든 브랜치의 분기·병합을 아스키 그래프로 시각화

특히 --oneline --graph 조합은 브랜치를 쓰기 시작하면 거의 매일 사용하게 됩니다. 프로젝트의 전체 흐름을 한눈에 파악할 수 있어, 복잡한 프로젝트일수록 진가를 발휘합니다.

7. git diff — 변경 내용 비교하기

파일을 수정했는데 정확히 어떤 줄이 바뀌었는지 확인하고 싶을 때 git diff를 씁니다.

• git diff — 작업 디렉토리와 스테이징 영역의 차이
• git diff --staged — 스테이징 영역과 마지막 커밋의 차이 (커밋 전 최종 점검용)
• git diff HEAD — 작업 디렉토리와 마지막 커밋의 전체 차이

커밋 직전에 git diff --staged로 한 번 더 확인하는 습관을 들이면 “아, 이 파일은 빼야 했는데” 하는 실수를 예방할 수 있습니다.

.gitignore — 추적하지 않을 파일 지정하기

프로젝트에는 Git으로 관리하면 안 되는 파일이 있습니다. 빌드 산출물, 환경 변수 파일, IDE 설정, 운영 체제가 자동 생성하는 파일 등이 대표적입니다. .gitignore 파일에 패턴을 등록하면 Git이 해당 파일을 자동으로 무시합니다.

프로젝트 루트에 .gitignore 파일을 만들고 무시할 패턴을 한 줄에 하나씩 적습니다. 실제 프로젝트에서 자주 쓰이는 패턴을 모아 보면 다음과 같습니다.

• node_modules/ — Node.js 패키지 폴더 (보통 수만 개 파일)
• __pycache__/ — Python 바이트코드 캐시
• .env — 환경 변수 파일 (비밀번호, API 키 등 민감 정보)
• *.log — 로그 파일
• dist/, build/ — 빌드 출력 폴더
• .DS_Store — macOS 폴더 메타데이터
• Thumbs.db — Windows 썸네일 캐시
• .idea/, .vscode/ — IDE 설정 (팀 공유 규칙이 없을 때)

보안 경고: .env처럼 비밀번호나 API 키가 들어 있는 파일은 반드시 .gitignore에 넣어야 합니다. 한 번이라도 커밋에 포함되면 히스토리에 영구히 남게 되어, 저장소가 공개될 경우 심각한 보안 사고로 이어질 수 있습니다. 실수로 올렸다면 커밋 히스토리에서 완전히 제거하는 별도의 작업이 필요합니다.

GitHub에서는 저장소를 만들 때 “Add .gitignore” 옵션에서 Python, Node, Java 등 언어·프레임워크별 템플릿을 선택할 수 있습니다. 직접 작성하는 것보다 이 템플릿을 기반으로 시작하는 것이 편리합니다.

브랜치와 머지 — 안전한 실험과 통합

Git의 진정한 힘은 브랜치(branch)에 있습니다. 브랜치는 “현재 코드를 그대로 두고, 별도의 작업 공간에서 새로운 기능을 만든다”는 개념입니다. 실험이 성공하면 원래 코드에 합치고(머지), 실패하면 브랜치만 삭제하면 됩니다. 본래 코드에는 아무 영향이 없습니다.

브랜치 기본 명령어

• git branch — 현재 브랜치 목록 확인 (* 표시가 현재 위치)
• git branch feature/login — 새 브랜치 생성
• git switch feature/login — 해당 브랜치로 전환 (Git 2.23+)
• git switch -c feature/signup — 생성과 전환을 한 번에
• git branch -d feature/login — 머지 완료된 브랜치 삭제

참고: 예전에는 git checkout으로 브랜치 전환을 했지만, 이 명령은 파일 복원과 브랜치 전환이라는 두 가지 역할이 섞여 혼란을 주었습니다. Git 2.23 버전부터 switch(브랜치 전환)와 restore(파일 복원)로 역할이 분리되었으므로, 새로 배우는 분은 switch를 사용하시길 권장합니다.

머지 — 브랜치 합치기

기능 개발이 끝나면 main 브랜치에 합쳐야 합니다.

• git switch main — 합칠 대상 브랜치(main)로 이동
• git merge feature/login — feature/login의 변경 사항을 main에 합침

같은 파일의 같은 줄을 양쪽 브랜치에서 각각 수정했다면 충돌(conflict)이 발생합니다. Git은 해당 파일에 충돌 표시를 남겨 줍니다.

• <<<<<<< HEAD 부분: 현재 브랜치(main)의 내용
• =======: 구분선
• >>>>>>> feature/login 부분: 합치려는 브랜치의 내용

이 표시를 직접 편집하여 원하는 최종 내용만 남긴 뒤, git add로 해결 완료를 알리고 git commit으로 머지 커밋을 만들면 됩니다. VS Code 같은 에디터에서는 “Accept Current”, “Accept Incoming”, “Accept Both” 버튼으로 더 직관적으로 해결할 수 있습니다.

브랜치 이름 규칙

혼자 작업할 때도 이름에 규칙을 두면 브랜치가 많아져도 혼란이 없습니다. 널리 쓰이는 접두어 패턴입니다.

• feature/ — 새 기능 개발 (예: feature/user-profile)
• fix/ — 버그 수정 (예: fix/login-error)
• hotfix/ — 긴급 수정
• docs/ — 문서 변경
• refactor/ — 코드 구조 개선

원격 저장소와 협업 — GitHub 연동

Git의 진가는 원격 저장소와 연동할 때 발휘됩니다. GitHub, GitLab, Bitbucket 같은 서비스에 코드를 올려 두면 어디서든 작업을 이어갈 수 있고, 팀원과 코드를 공유할 수 있습니다.

원격 저장소 연결과 push

로컬에서 git init으로 만든 저장소를 GitHub에 연결하려면 다음 명령을 사용합니다.

• git remote add origin https://github.com/사용자명/저장소.git — 원격 저장소 등록
• git remote -v — 등록된 원격 저장소 확인

여기서 origin은 원격 저장소의 별칭입니다. 관례적으로 기본 원격 저장소를 origin이라 부릅니다. 로컬 커밋을 원격에 올리려면 push를 사용합니다.

• git push -u origin main — 처음 한 번은 -u로 업스트림 설정
• 이후에는 git push만 입력해도 설정된 원격 브랜치로 자동 전송

pull과 fetch — 원격 변경 사항 가져오기

• git pull — 원격의 최신 변경을 가져와서 자동으로 머지 (= fetch + merge)
• git pull --rebase — 머지 커밋 없이 히스토리를 일직선으로 유지하며 가져오기
• git fetch — 원격 변경만 다운로드하되 로컬 브랜치에 합치지 않음

fetch는 “원격에 뭐가 바뀌었는지 먼저 확인하고, 내가 판단해서 합치겠다”는 신중한 접근입니다. git fetch origin 후 git log origin/main --oneline으로 변경 내용을 확인한 뒤 수동으로 merge하는 흐름입니다.

HTTPS vs SSH 인증

GitHub와 통신하는 방식은 크게 두 가지입니다.

• HTTPS: URL이 https://로 시작합니다. 초기 설정이 간편하지만 push할 때마다 인증이 필요합니다. GitHub CLI의 gh auth login이나 Git Credential Manager를 설정하면 인증 정보를 캐시하여 매번 입력할 필요가 없어집니다.
• SSH: URL이 [email protected]:으로 시작합니다. SSH 키 쌍을 한 번 만들어 GitHub에 등록하면 이후 비밀번호 입력 없이 사용할 수 있습니다. 보안과 편의성 양면에서 장기적으로는 SSH를 권장합니다.

실수 대처법 — 되돌리기와 복구

Git을 쓰다 보면 실수는 반드시 일어납니다. 중요한 것은 대처법을 알고 있느냐입니다. 상황별로 적절한 명령어를 정리해 두면 어떤 실수든 침착하게 복구할 수 있습니다.

git commit –amend — 직전 커밋 수정

방금 한 커밋의 메시지를 고치거나 빠뜨린 파일을 추가하고 싶을 때 사용합니다.

• git commit --amend -m "수정된 커밋 메시지" — 메시지만 변경
• git add 빠진파일.txt → git commit --amend --no-edit — 파일 추가, 메시지는 그대로 유지

주의: 이미 원격에 push한 커밋을 amend하면 히스토리가 꼬일 수 있습니다. amend는 push 전 로컬 커밋에만 사용하세요.

git reset — 커밋을 되돌리기

reset은 세 가지 모드에 따라 영향 범위가 달라집니다. 이 차이를 아는 것이 핵심입니다.

• git reset --soft HEAD~1 — 커밋만 취소하고, 변경 내용은 스테이징 영역에 남김. “커밋을 다시 정리하고 싶을 때” 사용.
• git reset --mixed HEAD~1 — 커밋과 스테이징을 취소하고, 변경은 작업 디렉토리에 남김. 기본 모드(–mixed 생략 가능).
• git reset --hard HEAD~1 — 커밋, 스테이징, 작업 디렉토리의 변경을 모두 삭제. 되돌릴 수 없으므로 신중하게 사용해야 합니다.

HEAD~1은 직전 커밋 한 개를 뜻합니다. HEAD~3이면 최근 세 개의 커밋을 되돌립니다.

git revert — 안전하게 되돌리기

reset이 히스토리를 수정하는 것이라면, revert는 “되돌리는 새 커밋”을 추가하는 방식입니다. 이전 히스토리가 그대로 보존되기 때문에, 이미 push한 커밋을 되돌릴 때는 항상 revert가 안전합니다.

• git revert HEAD — 직전 커밋의 변경을 취소하는 새 커밋 생성
• git revert abc1234 — 특정 커밋 해시를 지정해 되돌리기

git stash — 작업 내용 임시 저장

“기능 A를 개발하던 중 긴급하게 버그 B를 고쳐야 할 때” 가장 유용한 명령어입니다. 현재 변경 사항을 커밋하지 않고 임시로 치워 둔 뒤, 급한 일을 처리하고 돌아와서 복원할 수 있습니다.

• git stash — 현재 변경 사항을 임시 저장, 작업 디렉토리는 깨끗한 상태로
• git stash list — 저장된 stash 목록 확인
• git stash pop — 가장 최근 stash를 복원하면서 목록에서 제거
• git stash apply — 복원하되 목록에는 그대로 유지 (여러 곳에 적용할 때)

git reflog — 최후의 안전망

reflog는 Git의 숨겨진 보험 장치입니다. reset --hard로 커밋을 날려버린 것 같아도, reflog에는 HEAD가 이동한 모든 기록이 남아 있습니다.

• git reflog — HEAD 이동 히스토리 조회
• git reset --hard HEAD@{2} — reflog에서 특정 시점으로 복구

reflog 기록은 기본 90일간 보존됩니다. 실수를 발견했다면 서둘러 복구하면 대부분 살릴 수 있습니다. Git에서 데이터가 진짜로 영구히 사라지는 경우는 생각보다 훨씬 드뭅니다.

팀 협업 워크플로우 — PR 기반 개발

혼자 개발할 때는 main 브랜치에서 바로 작업해도 괜찮지만, 팀 프로젝트에서는 Pull Request(PR) 기반 워크플로우가 사실상 표준입니다. PR은 “내가 만든 변경을 리뷰한 뒤 main에 합쳐 주세요”라는 공식 요청입니다.

PR 기반 개발의 7단계

• 1단계: main에서 새 브랜치를 만들어 작업을 시작합니다. git switch -c feature/search
• 2단계: 기능 개발을 마치고 의미 있는 단위로 커밋합니다.
• 3단계: 원격에 브랜치를 push합니다. git push -u origin feature/search
• 4단계: GitHub에서 PR을 생성합니다. 변경 내용 요약, 테스트 방법, 관련 스크린샷 등을 본문에 적습니다.
• 5단계: 팀원이 코드를 리뷰합니다. 질문, 개선 제안, 수정 요청 등 피드백이 오갑니다.
• 6단계: 피드백을 반영하고, 승인(Approve)을 받으면 main에 머지합니다.
• 7단계: 머지 완료 후 feature 브랜치를 삭제해 정리합니다.

이 흐름을 GitHub Flow라고 부릅니다. 단순하면서도 효과적이어서, 빠른 배포 주기를 가진 대부분의 웹 서비스 팀에서 채택하고 있습니다. 반면 정기 릴리스 주기가 있는 모바일 앱 등에서는 develop, release, hotfix 브랜치를 추가하는 Git Flow 전략을 쓰기도 합니다. 처음 시작한다면 GitHub Flow를 권장합니다.

효과적인 코드 리뷰 팁

코드 리뷰는 단순히 버그를 찾는 것이 아니라, 팀 전체의 코드 품질과 지식 공유 수준을 높이는 과정입니다.

• PR은 작게: 변경 파일이 10개를 넘으면 리뷰어가 집중력을 잃기 쉽습니다. 가능하면 하나의 PR은 하나의 논리적 변경에 집중하세요.
• 맥락을 제공하세요: PR 본문에 “왜 이 변경이 필요한지”를 적으면 리뷰어가 의도를 빠르게 파악합니다.
• 건설적 피드백: “이상하다”보다 “이렇게 바꾸면 어떨까요?”처럼 구체적 대안을 제시하면 팀 분위기가 달라집니다.

알아 두면 유용한 고급 명령어

기초 명령어에 익숙해지면 다음 다섯 가지가 생산성을 한 단계 끌어올려 줍니다.

git rebase — 깔끔한 히스토리

merge와 결과는 같지만, 커밋 히스토리가 일직선으로 정리되어 깔끔합니다. feature 브랜치에서 git rebase main을 실행하면, feature의 커밋들이 main 최신 위로 재배치됩니다. 단, 이미 원격에 push한 브랜치에서는 히스토리 변경으로 인한 충돌 위험이 있으니 주의하세요.

git cherry-pick — 특정 커밋만 가져오기

다른 브랜치에 있는 특정 커밋 하나만 현재 브랜치에 적용하고 싶을 때 git cherry-pick 커밋해시를 사용합니다. 긴급 버그 수정을 여러 브랜치에 빠르게 적용해야 할 때 특히 유용합니다.

git bisect — 버그 원인 커밋 추적

“언제부터 이 버그가 생겼지?”를 이진 탐색으로 자동 추적하는 명령입니다. git bisect start → git bisect bad(현재, 버그 있음) → git bisect good v1.0(이 시점엔 버그 없음) — Git이 중간 커밋으로 자동 이동시켜 주고, 테스트 결과를 good/bad로 알려 주면 범위를 계속 절반으로 좁혀 나갑니다. 커밋이 수백 개여도 몇 분이면 범인을 찾습니다.

git blame — 각 줄의 작성자 추적

git blame 파일명은 해당 파일의 각 줄을 마지막으로 수정한 사람, 커밋 해시, 날짜를 표시합니다. 이름이 blame(비난)이지만, 실제로는 “이 코드의 맥락을 가장 잘 아는 사람이 누군지” 파악하는 데 쓰입니다.

git tag — 릴리스 버전 표시

git tag v1.0.0 또는 git tag -a v1.0.0 -m "첫 정식 릴리스"로 특정 커밋에 이정표를 남깁니다. git push origin v1.0.0으로 태그를 원격에 전송하면 GitHub Release 페이지에 자동 표시되어, 사용자에게 안정 버전을 배포하기 편리합니다.

Git Alias — 자주 쓰는 명령어 단축 등록

매일 쓰는 긴 명령어를 짧은 별칭으로 등록하면 타이핑이 줄고 작업이 빨라집니다.

• git config --global alias.st status → 이후 git st로 사용
• git config --global alias.co checkout → git co
• git config --global alias.br branch → git br
• git config --global alias.ci commit → git ci
• git config --global alias.lg "log --oneline --graph --all" → git lg로 전체 브랜치 그래프 보기

특히 git lg는 매우 강력합니다. 모든 브랜치의 히스토리를 컬러 그래프로 한눈에 보여 주어, 복잡한 프로젝트의 전체 흐름을 빠르게 파악할 수 있습니다. 별칭은 ~/.gitconfig 파일의 [alias] 섹션에 저장되므로 직접 편집해도 됩니다.

추천 Git GUI 도구

터미널에 익숙해지면 효율적이지만, 히스토리를 시각적으로 파악하거나 충돌을 해결할 때는 GUI 도구가 편리합니다.

• VS Code 내장 Git — 별도 설치 없이 바로 사용 가능합니다. 변경 사항 확인, 스테이징, 커밋, 브랜치 전환, diff 확인을 에디터 안에서 할 수 있어 초보자에게 가장 추천합니다.
• GitHub Desktop — GitHub 공식 도구로 깔끔한 인터페이스와 PR 생성이 통합되어 있습니다. Windows와 macOS를 모두 지원합니다.
• GitKraken — 강력한 브랜치 시각화와 드래그 앤 드롭 머지가 특징입니다. 공개 저장소 사용은 무료이며, 팀 기능은 유료입니다.
• SourceTree — Atlassian의 무료 Git GUI로, 보기 좋은 브랜치 그래프와 Git Flow 지원이 내장되어 있습니다.
• lazygit — 터미널 기반 TUI 도구입니다. 마우스 없이 키보드만으로 빠르게 Git을 조작할 수 있어, 터미널을 선호하지만 시각적 도움이 필요한 분에게 적합합니다.

처음에는 VS Code 내장 Git이나 GitHub Desktop으로 시작하세요. 명령어가 손에 익은 뒤에는 상황에 따라 터미널과 GUI를 자유롭게 오가는 것이 가장 효율적인 방법입니다.

자주 하는 실수와 해결 치트시트

Git을 쓰다가 한 번쯤 겪는 상황과 그 해결책을 한곳에 모았습니다. 이 부분을 북마크해 두면 당황할 때 바로 참고할 수 있습니다.

• 커밋 메시지를 잘못 적었다 → git commit --amend -m "올바른 메시지" (push 전에만)
• 스테이징에 올린 파일을 빼고 싶다 → git restore --staged 파일명
• 수정한 파일을 원래대로 되돌리고 싶다 → git restore 파일명 (저장 안 된 변경은 사라짐!)
• 방금 커밋을 취소하고 싶다 (변경 내용은 유지) → git reset --soft HEAD~1
• 이미 push한 커밋을 되돌려야 한다 → git revert HEAD
• 다른 브랜치에 할 작업을 main에 커밋해 버렸다 → git reset --soft HEAD~1 → git stash → git switch 올바른-브랜치 → git stash pop → 다시 커밋
• push가 rejected 됐다 → git pull --rebase로 원격 변경을 먼저 가져온 뒤 다시 push
• 머지 충돌이 너무 복잡해 머지를 취소하고 싶다 → git merge --abort
• 삭제한 커밋을 되살리고 싶다 → git reflog에서 해시 확인 후 git reset --hard HEAD@{n}

마무리 — Git은 근육과 같다

Git은 처음에 명령어가 많아 보이지만, 실제로 매일 쓰는 것은 status, add, commit, push, pull 정도입니다. 이 다섯 가지만 손에 익으면 나머지는 필요할 때마다 하나씩 추가하면 됩니다.

가장 좋은 학습법은 실제 프로젝트에 바로 적용하는 것입니다. 개인 프로젝트에 Git을 도입하고, 브랜치를 나눠 보고, 일부러 충돌을 만들어 해결해 보세요. reflog라는 안전망이 있으니 실수를 두려워할 필요가 없습니다.

2026년 현재 AI가 코드를 대신 작성해 주는 시대가 되었지만, 그 코드를 안전하게 관리하고, 이전 버전으로 되돌리고, 팀과 충돌 없이 공유하는 것은 여전히 Git의 몫입니다. 개발을 시작한 첫날부터 Git을 함께 배우는 것이 결코 이른 것이 아니라 — 딱 적절한 타이밍입니다. 오늘 git init 한 줄로 시작해 보세요.

이미지는 Leonardo AI 로 생성되었습니다.

이미지는 Claude AI 로 생성되었습니다.