99명

최근 30분간 동시 방문자 수를 표시합니다. (~)

최고 동시 방문자 수 -
어제: 0명 / 오늘: 0명

Git/GitHub 설치 및 사용 가이드

Git/GitHub 설치 및 사용 가이드

프로젝트를 개발하다 보면 새로운 기능 추가, 버그 수정, 성능 개선 등의 이유로 프로젝트 정보가 끊임없이 변경됩니다.
이런 변경 이력을 체계적으로 관리하지 않으면, 누가 어떤 수정을 했는지 추적하거나 이전 상태로 되돌리기도 어렵습니다.
버전 관리 시스템(VCS, Version Control System)인 Git을 사용하면 이러한 문제를 해결할 수 있으며, 또한 원격 저장소 서비스인 GitHub를 활용해 프로젝트를 쉽게 공유하고 협업할 수 있습니다.

버전 관리 시스템(VCS, Version Control System)은 파일의 변경 이력을 기록하고 관리하는 소프트웨어로, 다음과 같은 기능을 제공합니다.

  • 변경 이력 추적: 누가, 언제, 무엇을 변경했는지 확인할 수 있습니다.
  • 이전 상태로 복원: 코드에 문제가 생기면 이전 버전으로 되돌릴 수 있습니다.
  • 협업: 여러 사람이 동시에 코드를 수정하고 병합할 수 있습니다.
  • 백업: 코드를 원격 저장소와 연동해 안전하게 보관할 수 있습니다.

# 설치 및 구성

# Git 설치

Git 홈페이지

Git은 가장 널리 사용되는 분산형 버전 관리 시스템입니다.
리누스 토르발즈(Linus Torvalds)가 리눅스 커널 개발을 위해 2005년에 만들었습니다.

분산형(Distributed)이란 각 개발자가 전체 코드 이력의 복사본을 가지고 있다는 의미입니다.
서버가 다운되더라도 로컬에서 독립적으로 작업할 수 있습니다.

Windows의 경우, Git Install for Windows 페이지에서 설치 파일을 다운로드하여 설치 마법사를 따라 설치합니다.
설치가 완려되면 기존에 열려있는 터미널 창을 닫고 다시 열어야 합니다.

Git Install for Windows

설치 마법사 시작

가능하면 선택하되, 넘어가도 초기 구성에서 해결

설치 중..

설치 완료!

macOS에서는 Xcode Command Line Tools를 통해 설치하는 방법과 Homebrew를 사용하는 방법이 있습니다.
Xcode Command Line Tools에 포함된 Git은 Apple이 제공하는 버전입니다.
더 최신 버전이 필요하거나 쉽게 버전을 관리하려면, Homebrew를 사용하는 것이 좋습니다.

단순하게 Xcode Command Line Tools를 설치하려면 다음 명령을 실행합니다.
Git이 포함된 Xcode Command Line Tools가 설치됩니다.

BASH
1
xcode-select --install
Xcode Command Line Tools 설치

Homebrew를 사용하면 최신 버전의 Git을 쉽게 설치하고 관리할 수 있습니다.

BASH
1
brew install git
Homebrew로 Git 설치

Homebrew로 설치한 후에도 Xcode 버전의 Git이 동작할 수 있습니다.
이는 $PATH 환경변수에서 Xcode 버전의 Git 경로(/usr/bin)가 Homebrew 경로(/opt/homebrew/bin)보다 먼저 참조되기 때문으로, 터미널을 재시작하면 Homebrew 경로가 우선 적용될 수 있습니다.
which git 명령으로 Git 경로를 확인할 수 있습니다.

BASH
1
2
3
4
5
which git # /opt/homebrew/bin/git git -v # git version 2.47.1
Git 경로 확인(Apple Silicon)

# Git 초기 구성

Git을 처음 사용할 때는 먼저 사용자 정보를 구성해야 합니다.
이 정보는 버전(커밋)을 생성할 때 작성자 정보로 기록됩니다.

GitHub는 커밋의 이메일 주소와 사용자 이름을 기반으로 기여자를 식별하므로, 사용자 이름과 이메일을 GitHub의 계정 정보와 일치시키는 것이 좋습니다.
일치하지 않으면 커밋이 자신의 프로필에 연결되지 않을 수 있습니다.

BASH
1
2
git config --global user.name "ParkYoungWoong" git config --global user.email "thesecon@gmail.com"
사용자 정보

운영체제 간 줄바꿈 문자(개행 문자) 호환성을 위해 다음 구성도 추가합니다.

BASH
1
2
3
4
5
# macOS git config --global core.autocrlf input # Windows git config --global core.autocrlf true
개행 문자

개행 문자(Line Ending)는 텍스트에서 줄바꿈을 나타내는 보이지 않는 특수 문자입니다.
Windows는 CR LF(\r\n, 2바이트)를, macOS와 Linux는 LF(\n, 1바이트)를 사용합니다.
core.autocrlf 설정은 이 차이를 자동으로 변환해, 서로 다른 운영체제의 개발자가 협업할 때 불필요한 변경 이력이 생기는 것을 방지합니다.

메인 브랜치의 기본 이름을 main으로 지정합니다.

BASH
1
git config --global init.defaultBranch main
기본 브랜치 이름

Git 2.28 버전부터 init.defaultBranch 설정이 추가되었습니다.
이전에는 기본 브랜치 이름이 master였지만, 인종차별적 의미를 담고 있다는 사회적 논의를 계기로 2020년 말부터 GitHub를 비롯한 주요 플랫폼이 기본 브랜치 이름을 main으로 변경했습니다.

이제 모든 구성이 잘 등록되었는지 확인합니다.

BASH
1
2
3
4
5
6
git config --global --list # user.name=ParkYoungWoong # user.email=thesecon@gmail.com # core.autocrlf=input # true # init.defaultbranch=main
구성 목록 확인

한 번에 정리하면 다음과 같습니다.

BASH
1
2
3
4
5
git config --global user.name "ParkYoungWoong" git config --global user.email "thesecon@gmail.com" git config --global init.defaultBranch main git config --global core.autocrlf input # macOS git config --global core.autocrlf true # Windows
기본 구성

# GitHub 가입

GitHub는 Microsoft가 운영하는 Git 저장소를 온라인으로 호스팅하는 서비스로, 로컬에서만 관리하는 Git 저장소를 원격(Remote)으로 저장해서 관리할 수 있습니다.
이를 통해 코드를 보다 안전하게 백업하고 다른 개발자와 협업하며 오픈소스 프로젝트에 참여할 수 있습니다.
무료 계정으로도 공개 및 비공개 저장소를 무제한으로 생성할 수 있으므로, 개인 프로젝트부터 팀 협업까지 폭넓게 활용됩니다.

GitHub 회원가입 페이지에서 이메일, 비밀번호, 사용자 이름을 입력해 가입할 수 있습니다.
회원가입 후 이메일 인증을 완료하면 GitHub를 사용할 수 있습니다.

사용자 이름(Username)은 가입 후 변경할 수는 있지만, 저장소 URL 등 관련 주소가 바뀌므로 처음부터 신중하게 이름을 입력하는 것이 좋습니다.

GitHub 회원가입 양식

# GitHub 연동

GitHub 원격 저장소와 통신(push, pull 등)하려면 인증이 필요합니다.
인증 방식은 크게 HTTPS(자격증명)와 SSH 2가지가 있으며, 한 번만 설정해 두면 이후에는 별도의 입력 없이 사용할 수 있습니다.

처음부터 2가지 방식을 모두 설정해 두면 좋지만, 어렵다면 우선은 HTTPS 방식만 설정해도 됩니다.

# HTTPS (자격증명)

프로젝트를 처음 원격 저장소로 푸시(git push)하거나, 원격 저장소를 풀(git pull)할 때,
Windows에서는 Git을 설치하면 GCM(Git Credential Manager)가 함께 설치되어 자격증명 도우미가 자동으로 설정됩니다.
macOS에서 Xcode Command Line Tools로 Git을 설치한 경우, osxkeychain 도우미가 이미 설정되어 있을 수 있습니다.
Homebrew로 설치한 경우, GitHub CLI를 설치하면 gh auth login 명령으로 OAuth 인증을 통해 자격증명을 간편하게 설정할 수 있습니다.

BASH
1
brew install gh
Homebrew로 GitHub CLI 설치

자격증명 도우미가 설치된 환경에서는 다음과 같이 모달이 출력되어 브라우저에서 OAuth 방식으로 쉽게 인증할 수 있습니다.

Connect to GitHub

Authorize Git Credential Manager

Authentication Succeeded

만약 위와 같이 OAuth 방식의 인증이 아니라 터미널에서 직접 인증해야 하는 경우, 개인 액세스 토큰(PAT, Personal Access Token)을 사용해야 합니다.
비밀번호를 사용하는 방식은 2021년 8월부터 더 이상 지원하지 않습니다.

GitHub 사이트에서 로그인 후 토큰 관리 페이지로 접속합니다.
바로 접근이 되지 않으면, 다음 단계로 접근합니다.

  1. GitHub에 로그인합니다.
  2. 우측 상단의 프로필 아이콘 > Settings를 클릭합니다.
  3. 좌측 메뉴 하단의 Developer settings를 클릭합니다.
  4. Personal access tokens > Tokens (classic)을 선택합니다.

접근 후 다음 단계를 진행합니다.

  1. Generate new token > Generate new token (classic)을 클릭합니다.
  2. 토큰 정보를 입력합니다.
    1. Note 항목에 식별용 토큰 이름을 입력합니다.
    2. Expiration 항목에 토큰 만료일을 설정합니다.
      No expiration 을 선택하면 토큰이 만료되지 않아 다시 갱신할 필요가 없지만, 보안상 주의가 필요합니다.
    3. 저장소 접근 범위(Select scopes)를 선택합니다.
      일반적인 개발 작업(코드 push, pull 등)에는 repo와 workflow를 선택하면 충분합니다.
      필요 이상의 권한은 부여하지 않는 것이 좋고, 필요하면 이후에 권한을 추가로 부여할 수 있습니다.
  3. Generate token을 클릭해 토큰을 생성합니다
  4. 생성된 토큰을 복사합니다.

토큰은 생성 직후에만 확인할 수 있고 페이지를 벗어나면 다시 볼 수 없으므로, 바로 안전한 곳에 복사해 두세요.

New personal access token (classic)

위 과정을 완료하고 이후 과정에서 프로젝트를 처음 원격 저장소로 푸시(git push)하면, 아래와 같이 사용자 이름과 비밀번호를 입력하라는 메시지가 나타납니다.
사용자 이름(Username)에는 GitHub 사용자 이름을, 비밀번호(Password)에는 위에서 생성한 토큰을 붙여넣기합니다.
비밀번호에서는 보안상 입력 내용이 화면에 표시되지 않으므로, 토큰을 붙여넣기해도 아무것도 보이지 않을 수 있습니다.
그대로 엔터를 누르면 정상적으로 입력됩니다.
입력한 정보는 자격증명 도우미에 저장되며 이후에는 자동으로 인증됩니다.

BASH
1
2
Username for 'https://github.com': ParkYoungWoong # GitHub 사용자 이름 Password for 'https://ParkYoungWoong@github.com': # 토큰 붙여넣기 후 엔터

만약 저장된 자격증명을 조회, 수정, 삭제해야 할 경우, 운영체제별 자격증명 관리 도구를 사용합니다.
macOS의 경우 키체인 접근 앱에서 github.com 검색합니다.
Windows의 경우 제어판 > 사용자 계정 > 자격 증명 관리자에서 github.com 항목을 찾습니다.

macOS 키체인 접근 > 자격증명 확인

Windows 제어판 > 사용자 계정 > 자격 증명 관리자

# SSH

SSH(Secure Shell) 방식은 공개 키와 개인 키 한 쌍을 생성하고, 공개 키를 GitHub에 등록해 인증하는 방식입니다.
토큰처럼 만료일을 관리할 필요가 없어, 한 번 설정하면 편리하게 사용할 수 있습니다.

터미널에서 다음 명령어를 실행합니다.

BASH
1
ssh-keygen -t ed25519 -C "GitHub: ParkYoungWoong"

명령어의 각 옵션은 다음과 같은 의미를 가집니다.

  • -t: 키 타입을 지정합니다. rsa는 보다 오래된 키 타입이며, 명시적인 ed25519 사용을 추천합니다.
  • -C: 키를 식별하기 위한 주석을 작성합니다. 원하는 내용을 작성하면 됩니다.

그리고 다음과 같이 질문이 표시됩니다.
각 질문에서 엔터키를 누르면 기본 값이 사용되며, 원하는 경우 다른 값을 입력하면 됩니다.

BASH
1
2
3
4
5
6
7
8
# 키 이름과 저장 경로 지정 Enter file in which to save the key (/Users/사용자명/.ssh/id_ed25519): # 엔터 # 추가 암호 입력 Enter passphrase (empty for no passphrase): # 엔터 # 추가 암호 확인 Enter same passphrase again: # 엔터

완료되면 지정한 경로에 두 파일이 생성됩니다.
파일 이름은 지정한 키 이름(기본 id_ed25519)으로 구성되며 공개키는 pub 확장자가 붙습니다.
다음과 같은 파일(예시)이 생성됩니다.

  • 공개 키: id_ed25519.pub
  • 개인 키: id_ed25519

공개 키는 GitHub에 등록하고, 개인 키는 절대 외부에 공유해서는 안 됩니다!

이제 생성된 공개 키를 GitHub에 등록해 봅시다.
터미널에서 다음 명령어를 실행해 생성된 공개 키를 클립보드에 복사합니다.

BASH
1
2
3
4
5
6
7
# macOS # cat ~/.ssh/키이름.pub | pbcopy cat ~/.ssh/id_ed25519.pub | pbcopy # Windows (Git Bash) # cat ~/.ssh/키이름.pub | clip cat ~/.ssh/id_ed25519.pub | clip

GitHub 사이트에서 로그인 후 SSH 키 관리 페이지로 접속합니다.
페이지 링크로 바로 접근이 되지 않으면, 다음 단계로 접근합니다.

  1. GitHub에 로그인합니다.
  2. 우측 상단의 프로필 아이콘 > Settings를 클릭합니다.
  3. 좌측 메뉴 중간에서 SSH and GPG keys를 클릭합니다.

접근 후 다음 단계를 진행합니다.

  1. New SSH key를 클릭합니다.
  2. 키 정보를 입력합니다.
    1. Title 항목에 식별용 이름(예: my-laptop)을 입력합니다.
    2. Key type 항목에 Authentication key를 선택합니다.
    3. Key 항목에 복사한 공개 키를 붙여넣습니다.
  3. Add SSH key를 클릭해 키를 등록합니다.

Add new SSH Key

다음과 같이 터미널에서 SSH 키가 올바르게 등록되었는지 확인합니다.
만약 다음과 같이 SSH는 접속하는 서버가 GitHub인지 확인하기 위해 사용자에게 신뢰 여부를 묻는 경우, yes를 입력합니다.
그러면 GitHub의 호스트 키가 신뢰할 수 있는 서버로 등록됩니다.

BASH
1
2
3
4
5
ssh -T git@github.com # The authenticity of host 'github.com (20.200.245.247)' can't be established. # ED25519 key fingerprint is: SHA256:+DY3wvV6TuJJhbpZsF/zLDA0zMSvHdk4UvC0qU # This key is not known by any other names. # Are you sure you want to continue connecting (yes/no/[fingerprint])?
BASH
1
2
ssh -T git@github.com # Hi ParkYoungWoong! You've successfully authenticated, but GitHub does not provide shell access.
SSH 연결 확인!

깃 원격 저장소 등록을 할 때(git remote add) HTTPS 주소(https://github.com/사용자명/저장소명.git)를 사용하면 SSH 키가 아닌 HTTPS 인증을 사용합니다.
SSH 인증을 사용하려면 SSH 주소(git@github.com:사용자명/저장소명.git)를 사용해야 합니다.

GitHub 저장소에서 HTTPS 및 SSH 주소 확인

# 사용 가이드

# 작업 영역 이해

Git은 다음과 같이 3개의 주요 영역으로 파일을 관리합니다.

영역 설명
작업 디렉토리(Working Directory) 실제 파일을 편집하는 프로젝트 폴더
스테이징 영역(Staging Area) 다음 버전에 포함할 변경사항을 준비하는 임시 공간
저장소(Repository) 생성된 버전들이 저장되는 공간

버전 관리의 기본 작업 흐름은 다음과 같습니다.

  1. 프로젝트(작업 디렉토리)의 파일을 편집(생성, 수정, 삭제)합니다.
  2. git add 명령으로 변경사항을 스테이징 영역에 추가합니다.
  3. git commit 명령으로 버전을 생성합니다.

# 파일 상태 이해

Git으로 버전 관리하는 각 파일은 다음과 같은 상태를 가집니다.

상태 설명
Untracked Git이 아직 추적하지 않는 새 파일
Modified 추적 중인 파일이 수정된 상태
Staged 다음 버전에 포함되도록 준비된 상태
Committed 안전하게 저장소에 버전으로 기록된 상태

새로 만든 파일은 Untracked 상태에서 시작합니다.
git add로 스테이징하면 Staged 상태가 되고, git commit으로 버전을 생성하면 Committed 상태가 됩니다.
이미 커밋된 파일을 수정하면 Modified 상태로 변경되며, 다시 git add와 git commit을 통해 새 버전으로 기록할 수 있습니다.

git status 명령으로 현재 파일들의 상태를 확인할 수 있으며, VS Code 같은 에디터에서는 파일 이름 옆에 상태를 나타내는 기호가 표시됩니다.

파일 상태 표시

기호 의미 설명
M Modified 기존에 커밋된 파일이 변경된 상태
U Untracked 새로 생성되었지만 아직 Git에 추가되지 않은 상태
A Added 새로 생성되어 스테이징 영역에 추가된 상태
D Deleted 저장소에서 삭제된 파일
C Conflict 병합(Merge) 과정에서 충돌이 발생한 상태
R Renamed 이름이 변경된 파일

# 버전 관리 시작

프로젝트에서 Git 버전 관리를 시작하려면, 해당 프로젝트 폴더로 이동한 뒤 git init 명령을 실행합니다.
이를 버전 관리 초기화(Initialize)라고 하며, 프로젝트 단위로 처음에 한 번만 실행하면 됩니다.

BASH
1
2
3
cd my-project git init # Initialized empty Git repository in /Users/.../my-project/.git/
Git 저장소 초기화

명령을 실행하면 프로젝트 폴더 안에 .git이라는 숨김 폴더가 생성됩니다.
이 폴더에 모든 버전 관리 정보(커밋 이력, 브랜치, 설정 등)가 저장되며, 이 폴더가 있는 디렉토리가 곧 Git 저장소입니다.

이 폴더를 삭제하면 모든 버전 이력이 사라지므로 주의하세요.
혹은 이 폴더를 의도적으로 삭제해서 모든 버전 이력을 제거하고 다시 시작할 수도 있습니다.

# 상태 확인

현재 프로젝트의 파일 상태를 확인하려면 git status 명령을 사용합니다.
어떤 파일이 수정되었는지, 스테이징 되었는지, 아직 추적되지 않는 새 파일이 있는지 한눈에 파악할 수 있습니다.
작업 중간중간 자주 확인하는 것이 좋습니다.

BASH
1
git status

프로젝트에 파일을 새로 만들거나 수정하면 빨간색 글씨의 변경 상태(Untracked, Modified)로 표시됩니다.

현재 상태 확인

VS Code나 Cursor 같은 에디터를 사용하면, 소스 제어(Source Control) 패널에서 파일 상태를 확인할 수 있습니다.

VS Code > 소스 제어에서 상태 확인

# 스테이징

파일을 수정했다고 바로 버전이 만들어지는 것이 아닙니다.
버전을 생성하기 전에 먼저 git add 명령으로 변경된 파일을 스테이징 영역에 추가해야 합니다.
이를 스테이징(Staging)이라고 하며, "이 변경된 파일들을 다음 버전으로 포함하겠다!"고 선택하는 과정입니다.

모든 변경 파일을 스테이징할 때 뒤에 입력하는 .은 현재 경로를 의미하는데, 현재 경로의 변경된 모든 파일을 한 번에 스테이징한다는 것입니다.
특정 파일만 골라서 커밋하고 싶을 때는 파일 이름을 직접 지정하면 됩니다.

BASH
1
2
3
4
5
6
7
8
# 특정 파일 스테이징 git add index.html # 여러 파일 한번에 스테이징 git add index.html style.css main.js # 모든 변경 파일 스테이징 git add .
특정 파일 스테이징

위와 같이 스테이징 후 git status를 다시 실행하면, 초록색 글씨로 커밋할 변경사항(Changes to be committed)이 표시됩니다.

스테이징

VS Code나 Cursor 같은 에디터에서는 소스 제어 패널에서 쉽게 스테이징하고 확인할 수 있습니다.

VS Code > 소스 제어에서 모든 변경 내용 스테이징

VS Code > 소스 제어에서 스테이징된 변경사항 확인

# 커밋 전 비교

버전을 생성하는 것을 커밋(Commit)이라고 합니다.
커밋하기 전에 어떤 내용이 수정되었는지 확인하고 싶다면, git diff 명령을 사용할 수 있습니다.
추가된 줄은 초록색 글씨의 +, 삭제된 줄은 빨간색 글씨의 -로 표시되어 변경 내용을 쉽게 비교할 수 있습니다.

BASH
1
2
3
4
5
# 스테이징하지 않은 변경사항 확인 git diff # 스테이징된 변경사항 확인 git diff --staged
작업 디렉토리의 변경사항 확인 (아직 스테이징하지 않은 수정)

변경사항 확인

VS Code나 Cursor 같은 에디터에서는 소스 제어 패널에서 메시지를 작성하고 커밋할 수 있습니다.
VS Code에서는 소스 제어(Source Control) 패널에서 변경된 파일을 클릭하면 시각적으로 차이를 비교할 수 있습니다.
터미널 출력보다 직관적이므로, 에디터의 기능도 함께 활용하면 편리합니다.

VS Code > 소스 제어에서 변경사항 확인

# 커밋

스테이징된 변경사항이 준비되면, git commit 명령으로 커밋(Commit)을 생성할 수 있습니다.
-m 옵션(플래그) 뒤에 이 버전에서 무엇이 변경되었는지 설명하는 메시지(Message)를 작성할 수 있습니다.

BASH
1
git commit -m '커밋 메시지 작성..'

커밋 메시지는 나중에 이력을 살펴볼 때 각 버전의 내용을 빠르게 파악할 수 있도록 구체적이고 간결하게 작성하는 것이 좋습니다.

BASH
1
2
3
git commit -m '로그인 페이지 HTML 구조 작성.' git commit -m '헤더 내비게이션 링크 오류 수정.' git commit -m 'README 프로젝트 설명 추가.'
커밋 메시지 작성 예시

커밋 메시지를 작성할 때 닫는 따옴표(')를 입력하기 전에 엔터를 누르면 명령어 입력이 아닌 단순 줄바꿈으로 인식됩니다.
이렇게 하나의 -m 옵션 안에서 여러 줄을 작성할 수 있습니다.

BASH
1
2
git commit -m '이메일 형식과 비밀번호 길이를 검사합니다. 빈 값 제출 시 에러 메시지를 표시합니다.'
여러 줄의 커밋 메시지 작성

변경 내용이 많아 더 자세한 설명이 필요하다면, 커밋 메시지에 본문을 추가할 수 있습니다.
-m 옵션을 두 번 사용하면 첫 번째는 제목(Subject), 두 번째는 본문(Body)이 됩니다.

BASH
1
2
git commit -m '로그인 폼 유효성 검사 추가' -m '- 이메일 형식과 비밀번호 길이를 검사합니다. - 빈 값 제출 시 에러 메시지를 표시합니다.'
제목과 본문을 분리한 커밋 메시지

또는 -m 옵션 없이 git commit만 실행하면 텍스트 에디터(Vim)가 열리며, 여러 줄의 커밋 메시지를 자유롭게 작성할 수 있습니다.

BASH
1
git commit

에디터에서는 첫 줄이 제목, 한 줄 비우고 그 아래를 본문으로 인식합니다.
메시지를 작성한 후 파일을 저장하고 에디터를 닫으면 커밋이 완료되는데, 기본 에디터가 Vim인 경우 Esc → :wq → Enter를 눌러 저장 후 종료합니다.
저장하지 않고 종료하려면, Esc → :q! → Enter를 누릅니다.
메시지 하단에 자동으로 표시되는 주석(# 기호로 시작하는)은 제거해도 됩니다.

1
2
3
4
5
6
7
8
9
10
로그인 폼 유효성 검사 추가 이메일 형식과 비밀번호 길이를 검사합니다. 빈 값 제출 시 에러 메시지를 표시합니다. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # On branch main # Changes to be committed:
에디터에서 작성하는 커밋 메시지 형식

git commit 실행 시 열리는 기본 에디터 사용이 불편하다면, VS Code나 Cursor를 기본 에디터로 사용할 수 있습니다.
터미널에 다음과 같은 명령을 입력합니다.
이제 커밋하면 해당 에디터로 입력창이 열리고, 메시지를 작성한 후 저장하면 커밋이 완료됩니다.

BASH
1
2
3
4
5
# VS Code git config --global core.editor "code --wait" # Cursor git config --global core.editor "cursor --wait"

터미널에서 code나 cursor 같은 에디터 명령을 사용하려면, 각 에디터의 명령 팔레트에서 Shell Command: Install 'code(혹은 cursor)' command in PATH를 실행해 CLI를 먼저 설치해야 합니다.
명령 팔레트의 단축키는 Cmd(Ctrl) + Shift + P 입니다.

VS Code나 Cursor 같은 에디터에서는 소스 제어 패널에서 메시지를 작성하고 커밋할 수 있습니다.

VS Code 소스 제어 패널에서 메시지 작성 및 커밋

# 커밋 이력

지금까지 생성한 커밋 이력은 git log 명령으로 확인할 수 있습니다.
각 커밋의 커밋 ID(커밋 해시), 작성자, 날짜, 메시지가 최신순으로 표시됩니다.
커밋 ID는 커밋을 고유하게 식별하는 40자리 문자열로, 보통은 앞의 7자 정도만으로도 고유하게 식별할 수 있습니다.

BASH
1
2
b8c9d0db4e56836a8c1a0b9484375e01168d54d4 b8c9d0d
커밋 ID 예시
BASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
git log # commit b8c9d0d (HEAD -> main) # Author: ParkYoungWoong <thesecon@gmail.com> # Date: Fri Mar 6 14:22:05 2026 +0900 # # 첫 번째 페이지 작성 # # commit a1b2c3d # Author: ParkYoungWoong <thesecon@gmail.com> # Date: Fri Mar 6 13:15:42 2026 +0900 # # 로그인 페이지 HTML 구조 작성 # # --- 이하 생략 ---

이력이 많아지면 출력이 길어질 수 있습니다.
--oneline 옵션을 사용하면 각 커밋을 한 줄로 간결하게 확인할 수 있어 전체 흐름을 파악하기 좋습니다.

BASH
1
2
3
4
5
git log --oneline # b8c9d0d 첫 번째 페이지 작성 # a1b2c3d 로그인 페이지 HTML 구조 작성 # d4e5f6a 헤더 내비게이션 링크 오류 수정 # 7b8c9d0 README 프로젝트 설명 추가
한 줄로 간결하게 보기

VS Code나 Cursor 같은 에디터에서는 소스 제어 패널 하단의 그래프에서 커밋 이력을 확인할 수 있습니다.
이력을 선택하면 해당 커밋의 상세 정보를 확인할 수 있습니다.

VS Code 소스 제어 패널에서 커밋 이력 확인

# 리셋

리셋(Reset)은 과거 커밋으로 되돌아가는 명령어입니다.
커밋을 잘못 생성했거나 이전 상태로 돌아가고 싶을 때 git reset 명령을 사용할 수 있습니다.
리셋으로 돌아간 과거 이후의 커밋은 삭제되고 기본적으로는 복구할 수 없기 때문에, 반드시 명확하게 인식해 사용해야 합니다.

리셋은 정확하게는 HEAD 포인터를 이동시키는 명령어로, 엄밀히 말하면 커밋을 삭제하는 것은 아닙니다.
git reflog 명령으로 커밋 이력을 확인해 복구할 수 있지만, 진행 정도에 따라 복구가 어려울 수 있습니다.

BASH
1
2
# git reset <옵션> <포인터(커밋ID)> git reset --hard HEAD~1

되돌아갈 과거 커밋의 변경사항을 어떻게 처리할지에 따라 3가지 옵션을 제공할 수 있습니다.

옵션 작업 디렉토리 스테이징 영역 설명
--soft 유지 유지 커밋을 삭제하고 변경사항은 스테이징 영역에 유지
--mixed 유지 초기화 커밋을 삭제하고 변경사항은 작업 디렉토리에 유지(기본값)
--hard 초기화 초기화 커밋을 삭제하고 변경사항도 모두 삭제

자주 발생하는 상황은 '커밋을 하고 보니 문제가 발생해서 이전 상태로 돌아가고 싶을 때'입니다.
가장 최신 커밋을 삭제하고 그 전 커밋으로 돌아가되 변경사항은 유지한 채로 일부 내용을 수정해 다시 커밋할 예정이라면 --soft나 --mixed 옵션을 사용하면 됩니다.

--soft나 --mixed 옵션 선택이 어렵다면, 단순하게 기본값인 --mixed 옵션을 사용하세요.

BASH
1
2
3
git reset --mixed HEAD~1 # 혹은 git reset --soft HEAD~1

혹은 최신 커밋의 모든 변경사항이 필요하지 않고 다시 작업을 시작하고 싶다면, 과감하게 --hard 옵션을 사용합니다.

BASH
1
git reset --hard HEAD~1

HEAD는 가장 최신 커밋을 가리키는 포인터(Pointer)로, 뒤에 숫자를 지정해 몇 단계 전 커밋으로 되돌아갈지 지정할 수 있습니다.
HEAD~1은 HEAD~로 줄여 쓸 수 있으며, HEAD로부터 1개 전 커밋을 의미합니다.
HEAD~2는 2개 전 커밋, HEAD~3은 3개 전 커밋을 의미합니다.

혹은 원하는 7b8c9d0 같은 커밋 ID를 지정해 특정 커밋으로 되돌아갈 수 있습니다.
커밋 ID는 git log 명령 등으로 확인할 수 있습니다.

BASH
1
2
git reset --mixed HEAD~3 git reset --hard 7b8c9d0

HEAD~ 같은 포인터 방식은 가까운 최근 커밋 시점으로 되돌아갈 때 주로 사용합니다.
현재로부터 훨씬 멀리 떨어진 커밋 시점으로 되돌아갈 때는 7b8c9d0 같은 정확한 커밋 ID를 사용하는 것이 좋습니다.

# 브랜치

브랜치(Branch)는 독립적인 작업 공간을 만드는 기능입니다.
예를 들어 로그인 기능을 개발하면서 동시에 메인 페이지의 버그도 수정해야 한다면, 각각의 작업을 별도 브랜치에서 진행할 수 있습니다.
이렇게 하면 작업끼리 서로 영향을 주지 않고, 완료된 작업의 브랜치를 골라서 사용(병합)할 수 있습니다.

현재 저장소에 어떤 브랜치가 있는지 git branch 명령으로 목록을 확인할 수 있습니다.
* 표시가 현재 브랜치를 나타냅니다.

BASH
1
2
3
4
5
git branch # * main # feature/login # bugfix/header-color

새 브랜치를 만들 때는 git branch 명령 뒤에 브랜치 이름을 입력합니다.
이름은 작업 내용을 알 수 있도록 직관적이며 간결하게 짓는 것이 좋습니다.

브랜치를 생성하면 현재 브랜치의 모든 커밋 이력이 그대로 복사되고, 새로운 작업을 시작할 수 있습니다.

BASH
1
2
# git branch <브랜치명> git branch feature/login
새 브랜치 생성

생성된 다른 브랜치로 이동하려면 git switch 명령을 사용합니다.

BASH
1
2
# git switch <브랜치명> git switch feature/login

브랜치를 생성(Create)하면서 전환까지 한 번에 하려면 -c 옵션을 사용합니다.

BASH
1
2
# git switch -c <브랜치명> git switch -c feature/login

git checkout 명령으로도 브랜치를 전환할 수 있지만, Git 2.23부터 브랜치 전환 전용 명령인 git switch가 도입되었습니다.
checkout은 브랜치 전환 외에 파일 복원 등 여러 기능을 겸하고 있어 혼란을 줄 수 있으므로, 브랜치 전환에는 switch를 사용하는 것을 추천합니다.

더 이상 필요 없는 브랜치를 삭제(Delete)할 때는 git branch 명령 뒤에 -D 옵션을 사용합니다.
현재 브랜치는 삭제할 수 없으므로, 다른 브랜치로 이동한 뒤 삭제해야 합니다.

BASH
1
2
# git branch -D <브랜치명> git branch -D feature/login

브랜치에서 작업을 완료하고 커밋까지 마치고 그 변경사항을 다른 브랜치에 합쳐서 반영할 수 있습니다.
이를 병합(Merge)이라고 하며, 병합할 브랜치로 먼저 이동한 뒤 git merge 명령을 실행합니다.
병합이 완료되면 해당(수신) 브랜치의 커밋 이력이 현재 브랜치에 반영됩니다.

이해를 돕기 위해서 main 브랜치에서 feature/login 브랜치를 병합하는 예시를 들었습니다.

BASH
1
2
3
4
5
# 병합할 브랜치로 이동 git switch main # main 브랜치에 feature/login 브랜치를 병합 git merge feature/login

만약, 서로 다른 브랜치에서 같은 파일의 같은 부분을 수정한 경우, 병합할 때 충돌(Conflict)이 발생할 수 있습니다.
충돌이 발생하면 Git은 해당 파일에 양쪽의 변경 내용을 모두 표시해 줍니다.

HTML
1
2
3
4
5
<<<<<<< HEAD <h1>Hello Git!</h1> ======= <h2>Hello GitHub!</h2> >>>>>>> feature/login

VS Code에서 충돌 확인

<<<<<<< HEAD부터 =======까지는 현재 브랜치(main)의 내용입니다.
=======부터 >>>>>>>까지는 병합하려는 수신 브랜치(feature/login)의 내용입니다.
둘 중 원하는 내용을 선택하거나, 두 내용을 조합해서 수정한 뒤 충돌 표시(<<<<<<<, =======, >>>>>>>)를 모두 제거합니다.

충돌을 해결한 후, 해당 파일을 git add 명령으로 스테이징하고 git commit 명령으로 커밋하면 병합이 완료됩니다.

BASH
1
2
3
# main 브랜치에서 충돌 해결 git add index.html git commit -m 'main과 feature/login 충돌 해결'
충돌 해결 후 병합 완료

# 원격 저장소 생성

GitHub에서 새 원격 저장소를 만드는 방법은 다음과 같습니다.

  1. GitHub에 로그인합니다.
  2. 우측 상단의 + 버튼 > New repository를 클릭합니다.

New repository

  1. 저장소 이름(Repository name)을 입력합니다.
  2. 저장소의 공개(Public) 또는 비공개(Private) 여부를 선택합니다.
  3. Create repository를 클릭합니다.

Create a new repository

우리는 로컬 저장소의 작업을 원격 저장소로 업로드(Push)하기 위해서 GitHub에 새 저장소를 만들었기 때문에, README, .gitignore 등의 추가 옵션을 선택하면 원격 저장소에 자동으로 파일이 추가되므로 업로드 과정에서 충돌이 발생합니다.

# 원격 저장소 등록

원격 저장소를 생성했으니 업로드(Push)할 수 있도록 로컬 저장소에서 원격 저장소의 주소를 등록해야 합니다.
별칭(Alias)은 원격 저장소를 지칭하는 이름으로, 관례적으로 origin을 사용합니다.
원하는 경우, origin 대신 다른 이름을 사용해도 됩니다.

BASH
1
2
3
4
5
6
7
# git remote add <별칭> <원격_저장소> # HTTPS git remote add origin https://github.com/사용자명/저장소명.git # SSH git remote add origin git@github.com:사용자명/저장소명.git

등록이 잘 되었는지 확인하려면 다음 명령을 실행합니다.
등록한 원격 저장소의 HTTPS 혹은 SSH 주소가 표시돼야 합니다.

BASH
1
2
3
git remote -v # origin https://github.com/사용자명/저장소명.git (fetch) # origin https://github.com/사용자명/저장소명.git (push)
원격 저장소 확인

# 코드 밀어내기

로컬에서 생성한 커밋 이력을 원격 저장소에 업로드하는 것을 푸시(Push)라고 합니다.
git push 명령으로 실행합니다.

BASH
1
2
# git push <원격_저장소_별칭> <브랜치명> git push origin main

-u 옵션을 사용해 추적할 브랜치를 지정(업스트림, Upstream)하면 이후에는 git push만으로 간단히 푸시할 수 있습니다.
브랜치를 변경하면 다시 -u 옵션으로 업스트림을 설정해야 합니다.

BASH
1
2
3
4
5
# 첫 번째 푸시 git push -u origin main # 이후 푸시 git push

# 코드 당겨오기

다른 환경에서 작업하거나 팀원이 코드를 수정해서 원격 저장소가 업데이트된 경우, 원격 저장소의 최신 변경사항을 로컬로 가져와야 합니다.
이를 풀(Pull)이라고 하며, git pull 명령으로 실행합니다.

BASH
1
2
# git pull <원격_저장소_별칭> <브랜치명> git pull origin main

git push에서 -u 옵션으로 업스트림을 설정한 경우, 별칭과 브랜치명을 생략하고 git pull만 입력해도 됩니다.

BASH
1
git pull

git pull은 내부적으로 다음과 같은 두 단계를 수행합니다.
즉, git pull은 원격의 변경사항을 가져오고 자동으로 병합까지 해주는 명령입니다.

  1. git fetch: 원격 저장소의 최신 이력을 로컬로 가져오되, 로컬 파일은 변경되지 않습니다.
  2. git merge: 가져온 이력을 현재 브랜치에 병합해, 로컬 파일을 업데이트합니다.

원격 저장소와 로컬 저장소에서 같은 파일의 같은 부분을 서로 다르게 수정한 경우, git pull 시 충돌(Conflict)이 발생할 수 있습니다.
이는 브랜치 병합에서의 충돌과 동일한 방식으로, 충돌이 발생한 파일을 열어 원하는 내용으로 수정해 해결합니다.

# 저장소 복제

이미 GitHub에 존재하는 원격 저장소를 로컬로 가져오려면 git clone 명령을 사용합니다.
한 번에 원격 저장소의 프로젝트 내용과 커밋 이력, 브랜치 등을 모두 가져옵니다.

BASH
1
2
3
4
5
# HTTPS git clone https://github.com/사용자명/저장소명.git # SSH git clone git@github.com:사용자명/저장소명.git
저장소 복제

기본적으로 저장소 이름과 같은 폴더가 생성되지만, 원하는 폴더 이름을 직접 지정할 수도 있습니다.

BASH
1
git clone https://github.com/사용자명/저장소명.git my-project
특정 폴더명으로 복제

# 버전 관리 무시

프로젝트에는 버전 관리가 필요하지 않거나 공유하면 안 되는 파일이 있습니다.
예를 들어, node_modules 같은 의존성 폴더나 .env 같은 환경 변수 파일이 대표적입니다.
.gitignore 파일에 이런 파일이나 폴더의 패턴을 작성해 두면 Git이 해당 항목을 자동으로 무시합니다.

/.gitignore
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 의존성 폴더 node_modules/ # 환경 변수 파일 .env .env.local # 빌드 결과물 dist/ build/ # OS 생성 파일 .DS_Store Thumbs.db

.gitignore는 프로젝트 루트에 위치하며, Git 저장소를 git init 명령으로 초기화한 직후에 바로 만드는 것이 좋습니다.
이미 추적이 시작된 파일은 .gitignore에 추가해도 자동으로 무시되지 않습니다.
만약 추적을 중단하려면, git rm --cached <파일명> 명령을 사용해야 합니다.

# 워크플로우

지금까지 배운 명령어들을 활용하는 기본적인 워크플로우를 살펴봅시다.
자신의 상황에 맞는 워크플로우를 참고하고 다양하게 응용해 보세요.

# 새 프로젝트 시작

로컬에서 새 프로젝트를 만들고 GitHub에 푸시하는 과정입니다.

BASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# 1. 프로젝트 폴더 생성 및 이동 mkdir my-project cd my-project # 2. 버전 관리 초기화 git init # 3. 버전 관리 무시 파일 생성 및 작성 touch .gitignore # 4. 파일 생성 및 작성 등의 작업 # 5. 스테이징 git add . # 6. 첫 번째 커밋 git commit -m '프로젝트 생성.' # 4~6번을 반복해 모든 작업을 완료 # 7. GitHub 원격 저장소 생성 후 연결(HTTPS/SSH) git remote add origin https://github.com/사용자명/저장소명.git # 8. GitHub 원격 저장소에 푸시 git push origin main

# 원격 저장소에서 시작

이미 GitHub 저장소가 있는 기존 프로젝트에 참여할 때의 과정입니다.
예를 들어, 팀원이 만든 팀 프로젝트에 합류하거나, 집 컴퓨터에서 회사 프로젝트를 이어 작업하는 경우가 해당합니다.
git clone으로 저장소를 복제하면 프로젝트의 모든 파일과 커밋 이력을 한 번에 가져와 바로 작업을 시작할 수 있습니다.

BASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 1. 원격 저장소 복제(HTTPS/SSH) git clone https://github.com/사용자명/저장소명.git # 2. 프로젝트 폴더로 이동 cd 저장소명 # 3. 파일 수정 등의 작업 # 4. 스테이징 git add . # 5. 커밋 git commit -m '버그 수정' # 6. GitHub 원격 저장소에 푸시 git push

# 일상적인 작업 흐름

프로젝트 초기 세팅이 끝난 후, 자주 반복하게 되는 가장 기본적인 워크플로우입니다.
작업 시작 전에 원격의 최신 코드를 가져와서(Pull), 작업 후 커밋하고 푸시(Push)하는 순서로 변경사항을 원격에 올립니다.

BASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 1. 원격의 최신 코드 가져오기 git pull # 2. 파일 수정 등의 작업 # 3. 상태 및 변경사항 확인 git status git diff # 4. 스테이징 git add . # 5. 커밋 git commit -m '소개 섹션 추가' # 6. GitHub 원격 저장소에 푸시 git push

# 브랜치를 활용한 작업 흐름

새로운 기능을 추가하거나 버그를 수정할 때, main이라는 주 브랜치에서 바로 작업하면 문제가 생겼을 때 되돌리기가 어렵습니다.
별도 브랜치를 만들어 작업하면 main 브랜치는 항상 안정적인 상태로 유지할 수 있고, 작업이 잘못되더라도 해당 브랜치만 삭제하면 됩니다.
작업이 완료되면 main 브랜치에 병합하고, 사용이 끝난 브랜치는 삭제합니다.

BASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# 1. 최신 코드 받기 git pull # 2. 작업할 새 브랜치 생성 및 이동 git switch -c feature/login # 3. 파일 수정, 스테이징, 커밋 등 필요한 만큼 반복 git add . git commit -m '로그인 폼 HTML 작성' git add . git commit -m '로그인 유효성 검사 추가' # 4. main 브랜치로 이동 git switch main # 5. 작업 브랜치 병합 git merge feature/login # 6. 원격에 Push git push # 7. 병합이 끝난 브랜치 삭제 git branch -D feature/login

GitHub을 사용하는 만큼, 병합은 로컬보다는 원격에서 Pull Request를 통해 진행하는 것이 좋습니다.
관련 내용은 사례로 이해하는 GitHub Flow를 참고하세요.
그리고 Git에서 사용할 수 있는 더 자세하고 다양한 명령은 Git 핵심 명령어 모음을 참고하세요!