git.learn
0%
⎇ Complete Korean Edition · Full Detail

Git & GitHub 완전 정복

설치부터 오픈소스 기여까지 — 실무 협업의 모든 것을 담은 완전 한국어 교재

9챕터
3파트
50+실습 예제
35+핵심 명령어
01부 · 기초편 (1~5장)
02부 · 실전편 (6~7장)
03부 · GUI편 (8~9장)
01부 · 기초편
01

1장: 들어가며

이 장은 Git을 처음 접하는 독자를 위한 출발점입니다. Git이 왜 필요한지 실제 업무 상황을 통해 살펴보고, 윈도우·macOS에 Git을 설치하고, VS Code를 개발 환경으로 구성하는 방법까지 단계적으로 안내합니다.

버전관리Git 소개설치VS Code

1.1 Git이 없던 회사

개발자가 팀에 합류했을 때 가장 먼저 마주치는 충격 중 하나가 있습니다. 팀 공유 드라이브에는 프로젝트_최종.zip, 프로젝트_최최종.zip, 프로젝트_진짜최종_231210.zip 같은 파일들이 잔뜩 쌓여 있습니다. 어떤 파일이 "진짜" 최신인지, 무엇이 바뀌었는지 알 길이 없습니다.

이것은 버전 관리(Version Control)가 없는 환경의 전형적인 모습입니다. 코드뿐 아니라 기획서, 디자인 파일, 스프레드시트를 다루는 모든 팀에서 발생합니다.

⚠️ 버전 관리 없는 협업의 5대 재앙
  • 파일 폭발 — "최종"이라는 이름의 파일이 수십 개 생기고, 어느 것이 진짜 최신인지 아무도 모릅니다.
  • 변경 이유 불명 — 누가, 언제, 왜 코드를 수정했는지 추적할 방법이 없습니다. 버그 발생 시 원인 규명이 거의 불가능합니다.
  • 덮어쓰기 사고 — 두 사람이 같은 파일을 동시에 수정한 뒤 한 명이 업로드하면, 다른 사람의 작업이 그냥 사라집니다.
  • 롤백 불가 — 기능을 추가했다가 문제가 생겨도 과거 상태로 되돌릴 방법이 없습니다.
  • 배포 사고 — "잘 되던 버전"이 어느 파일이었는지 몰라 심야 장애가 길어집니다.

Git은 이 모든 문제를 해결하는 분산 버전 관리 시스템(DVCS, Distributed Version Control System)입니다. 파일의 모든 변경 이력을 시간 순으로 저장하여 언제든 과거로 돌아갈 수 있고, 누가 무엇을 언제 왜 바꿨는지 투명하게 기록합니다.

VCS / DVCS
VCS(Version Control System): 파일 변경 사항을 시간 순으로 추적하는 시스템. DVCS는 여기서 한 발 더 나아가, 모든 참여자가 전체 이력의 복사본을 로컬에 가집니다. 서버가 다운돼도 작업이 가능하고, 오프라인에서도 커밋·브랜치 등 거의 모든 작업을 수행할 수 있습니다.

1.2 리더의 제안

팀 리더가 "우리도 Git 도입합시다"라고 했을 때, 개발자들은 보통 두 가지 반응을 보입니다. "드디어!"와 "어렵지 않아요?"입니다.

Git의 진입 장벽은 사실 다음 세 가지 명령어로 시작합니다:

작업한다
git add
git commit
git push

나머지는 이 기본 흐름을 확장하는 것입니다. 이 책은 "Git 사용 경험 없음"을 전제로, 개념 이해 → CLI 실습 → VS Code GUI 실습의 3단계로 단단하게 쌓아갑니다.

💡
이 책의 학습 순서
CLI(명령줄 인터페이스)를 먼저 배우는 이유는 원리를 이해하기 위해서입니다. GUI는 내부적으로 CLI 명령어를 실행하므로, CLI를 알면 어떤 환경에서도 Git을 사용할 수 있습니다. CLI에 익숙해지면 VS Code, GitHub Desktop 같은 GUI 도구를 훨씬 자신 있게 다룰 수 있습니다.

1.3 Git 설치

Git은 공식 웹사이트 git-scm.com에서 모든 운영체제용 버전을 무료로 제공합니다. 설치 전에 이미 설치되어 있는지 먼저 확인하세요.

1.3.1 윈도우 환경에서 Git 설치하기

윈도우에서 Git을 설치하면 Git Bash도 함께 설치됩니다. Git Bash는 리눅스/macOS 스타일의 명령어를 윈도우에서 사용할 수 있게 해주는 터미널입니다.

  1. 공식 사이트 다운로드
    https://git-scm.com/download/win에 접속합니다. 64-bit 버전을 내려받으세요.
  2. 설치 옵션 — Adjusting your PATH
    "Git from the command line and also from 3rd-party software"를 선택합니다. 이 옵션을 선택해야 PowerShell과 명령 프롬프트에서도 git 명령어를 사용할 수 있습니다.
  3. 설치 옵션 — 기본 에디터
    "Use Visual Studio Code as Git's default editor"를 선택하면 커밋 메시지 편집 시 VS Code가 열립니다.
  4. 설치 옵션 — 기본 브랜치명
    "Override the default branch name for new repositories"를 선택하고 main을 입력합니다. 현재 업계 표준이 master에서 main으로 전환되었습니다.
  5. 설치 완료 확인
    명령 프롬프트(cmd) 또는 PowerShell을 열고 아래 명령어로 확인합니다.
명령 프롬프트 / PowerShellbash
C:\Users\user> git --version git version 2.44.0.windows.1 # 위와 같이 버전이 출력되면 설치 성공입니다
⚠️
설치 후 터미널을 새로 열어야 합니다
Git을 설치한 후에는 이미 열려 있던 터미널을 닫고 새로 열어야 git 명령어가 인식됩니다. PATH 환경 변수가 새 터미널 창에서만 적용되기 때문입니다.
1.3.2 macOS 환경에서 Git 설치하기

macOS에는 Xcode Command Line Tools에 Git이 포함되어 있어 이미 설치되어 있을 수 있습니다. 하지만 버전이 오래되었을 수 있으므로 Homebrew로 최신 버전을 설치하는 것이 좋습니다.

터미널 (macOS)bash
# 이미 설치되어 있는지 확인 $ git --version # 없거나 오래됐다면 Homebrew 설치 후 Git 설치 # Step 1: Homebrew 설치 (이미 있다면 생략) $ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" # Step 2: Git 설치 $ brew install git # Step 3: 설치 확인 $ git --version git version 2.44.0 # Step 4: which git으로 경로 확인 (Homebrew 버전이 우선시되어야 함) $ which git /opt/homebrew/bin/git
ℹ️
Apple Silicon(M1/M2/M3) Mac
Apple Silicon Mac에서는 Homebrew가 /opt/homebrew에 설치됩니다. Intel Mac은 /usr/local입니다. which git 결과가 /usr/bin/git이면 기본 Git이 사용 중이므로, Homebrew 경로가 PATH에 앞서 있는지 확인하세요.

1.4 VS Code 설치

Visual Studio Code(VS Code)는 Microsoft가 만든 무료 오픈소스 코드 에디터입니다. Git 통합이 뛰어나고, 수천 개의 확장 프로그램이 있으며, 현재 세계에서 가장 널리 사용되는 개발 도구입니다.

  1. 다운로드
    https://code.visualstudio.com에서 운영체제에 맞는 설치 파일을 내려받습니다.
  2. 윈도우 설치 옵션
    "Add to PATH""Open with Code" 옵션을 체크합니다. PATH 추가 시 터미널에서 code .로 현재 폴더를 바로 열 수 있습니다.
  3. 필수 확장 프로그램 설치
    VS Code를 열고 좌측 확장(Extensions) 아이콘 클릭 → 아래 확장을 검색해 설치합니다.
확장 이름역할필요도
Git Graph브랜치 히스토리를 시각적 그래프로 표시강력 추천
GitLens각 줄마다 커밋 작성자·일시를 인라인 표시추천
Korean Language PackVS Code UI 한국어화선택
터미널에서 VS Code로 폴더 열기bash
# 현재 디렉터리를 VS Code로 바로 열기 $ code . # 특정 폴더 열기 $ code ~/my-project
01부 · 기초편
02

2장: 전지전능한 관찰자 Git

Git을 프로젝트에 처음 연결하는 과정입니다. git init으로 저장소를 생성하고, 사용자 정보를 설정하며, CLI와 VS Code 두 가지 방법으로 Git을 프로젝트에 적용하는 방법을 상세히 익힙니다.

git initgit configRepository.gitVS Code
🔗 2장 실습 링크 — git init & 설정

2.1 Git과 계약을 맺다 — git init

Git은 스스로 아무 폴더에나 붙어있지 않습니다. 개발자가 명시적으로 "이 폴더를 Git으로 관리하겠다"고 선언해야 합니다. 이 선언이 바로 git init입니다. 이 명령어를 실행하는 순간, Git이 해당 폴더의 전지전능한 관찰자가 됩니다.

Repository (저장소)
Git이 관리하는 프로젝트 디렉터리 전체를 가리킵니다. git init을 실행하면 숨김 폴더 .git/이 생성되는데, 이 안에 모든 커밋 이력, 브랜치 정보, 설정 등이 저장됩니다. .git/ 폴더가 있는 디렉터리 = Repository입니다.
my-project/         ← 작업 디렉터리 (Working Directory)
├── .git/           ← Git의 데이터베이스 (절대 수동 편집 금지!)
│   ├── HEAD        ← 현재 브랜치를 가리키는 포인터
│   ├── config      ← 저장소 설정
│   ├── objects/    ← 커밋, 파일 내용이 압축 저장됨
│   └── refs/       ← 브랜치, 태그 포인터
├── index.html      ← 실제 작업 파일들
└── style.css
🚨
.git 폴더를 삭제하면 모든 이력이 사라집니다
.git 폴더에는 프로젝트의 전체 버전 이력이 들어 있습니다. 이 폴더를 실수로 삭제하면 커밋 이력이 복구 불가능하게 사라집니다. 절대 삭제하지 마세요. 탐색기에서 숨김 파일을 표시하지 않으면 이 폴더는 보이지 않으므로 상대적으로 안전합니다.

2.2 내 프로젝트에 Git 설정하기 — CLI

CLI(Command Line Interface)로 Git을 설정하는 전체 흐름입니다. 처음 한 번만 하는 전역(Global) 설정과, 저장소마다 하는 로컬(Local) 설정으로 나뉩니다.

2.2.1 윈도우 환경에서 명령 프롬프트 실행하기

윈도우에서 CLI를 여는 방법은 세 가지입니다:

  • 명령 프롬프트(cmd): Win + Rcmd 입력 → Enter. 가장 기본적인 터미널입니다.
  • PowerShell: 시작 메뉴에서 "PowerShell" 검색. cmd보다 강력하며 Git을 잘 지원합니다.
  • Git Bash: Git 설치 시 함께 설치됩니다. 리눅스/macOS 명령어를 그대로 사용할 수 있어 이 책의 예제와 가장 잘 맞습니다. 바탕화면 우클릭 → "Git Bash Here"로 빠르게 열 수 있습니다.
💡
이 책에서는 Git Bash 사용을 권장합니다
Git Bash에서는 ls, mkdir, touch 등 리눅스 명령어가 그대로 동작하므로, macOS/리눅스 사용자와 동일한 명령어를 사용할 수 있습니다. VS Code 내장 터미널에서도 Git Bash를 기본으로 설정할 수 있습니다.
2.2.2 macOS 환경에서 터미널 실행하기

macOS에서 터미널을 여는 방법:

  • Spotlight: Cmd + Space → "Terminal" 입력 → Enter
  • Finder: 응용 프로그램 → 유틸리티 → 터미널
  • Launchpad: 기타 폴더 → 터미널
💡
iTerm2 추천
기본 터미널 대신 iTerm2를 사용하면 탭, 분할 화면, 색상 테마 등 훨씬 편리한 기능을 쓸 수 있습니다. https://iterm2.com에서 무료로 다운로드 가능합니다.
2.2.3 Git 최초 설정 — 사용자 정보 등록

Git을 처음 설치하면 반드시 사용자 이름과 이메일을 등록해야 합니다. 이 정보는 커밋마다 "작성자"로 기록됩니다. 팀에서 협업할 때 누가 무엇을 했는지 추적하는 핵심 정보입니다.

전역(Global) 사용자 정보 설정bash
# 이름 설정 (커밋 로그에 표시될 이름) $ git config --global user.name "홍길동" # 이메일 설정 (GitHub 계정 이메일과 일치시키는 것 권장) $ git config --global user.email "hong@example.com" # 기본 브랜치명을 main으로 (GitHub 기본값과 일치) $ git config --global init.defaultBranch main # 줄바꿈 처리 (Windows는 true, Mac/Linux는 input) $ git config --global core.autocrlf true # Windows $ git config --global core.autocrlf input # Mac/Linux # 설정 확인 (모든 항목 출력) $ git config --list user.name=홍길동 user.email=hong@example.com init.defaultbranch=main core.autocrlf=true # 특정 항목만 확인 $ git config user.name 홍길동 # 설정 파일 위치: ~/.gitconfig (홈 디렉터리) $ cat ~/.gitconfig [user] name = 홍길동 email = hong@example.com [init] defaultBranch = main
ℹ️
--global vs --local
--global은 이 컴퓨터의 모든 Git 저장소에 적용됩니다. 특정 저장소에만 다른 설정을 쓰고 싶다면 --local을 사용합니다. 예를 들어 회사 저장소에서는 회사 이메일을, 개인 저장소에서는 개인 이메일을 쓰고 싶을 때 유용합니다.
2.2.4 작업할 프로젝트 디렉터리 생성
디렉터리 생성 및 이동bash
# 홈 디렉터리로 이동 $ cd ~ # 프로젝트 폴더 생성 $ mkdir my-project # 폴더로 이동 $ cd my-project # 현재 위치 확인 $ pwd /Users/hong/my-project # 폴더 내용 확인 (아직 비어있음) $ ls -la total 0 drwxr-xr-x 2 hong staff 64 4 4 10:00 . drwxr-xr-x 5 hong staff 160 4 4 10:00 ..
2.2.5 Git 저장소 생성 — git init
git init 실행bash
$ git init Initialized empty Git repository in /Users/hong/my-project/.git/ # 숨김 파일 포함 목록 확인 (-a 옵션) $ ls -la drwxr-xr-x 3 hong staff 96 4 4 10:01 . drwxr-xr-x 5 hong staff 160 4 4 10:01 .. drwxr-xr-x 9 hong staff 288 4 4 10:01 .git # .git 내부 구조 확인 $ ls .git/ HEAD config description hooks info objects refs # HEAD 파일 확인 → 현재 main 브랜치를 가리킴 $ cat .git/HEAD ref: refs/heads/main

2.3 내 프로젝트에 Git 설정하기 — VS Code

CLI 없이 VS Code의 GUI만으로도 Git 저장소를 초기화할 수 있습니다. VS Code는 Git을 기본 내장하고 있습니다.

  1. VS Code로 폴더 열기
    파일(File) → 폴더 열기(Open Folder) 메뉴에서 작업할 폴더를 선택합니다. 또는 터미널에서 code .로 현재 폴더를 바로 엽니다.
  2. 소스 제어 패널 열기
    좌측 사이드바에서 분기 아이콘(소스 제어, 단축키: Ctrl+Shift+G / Cmd+Shift+G)을 클릭합니다.
  3. "저장소 초기화" 클릭
    소스 제어 패널에 "저장소 초기화(Initialize Repository)" 버튼이 표시됩니다. 클릭하면 git init이 실행됩니다.
  4. 초기화 확인
    상태 표시줄 좌측 하단에 브랜치 이름(main)이 나타나면 성공입니다.
💡
VS Code 통합 터미널 활용
VS Code 내장 터미널(Ctrl+` / Cmd+`)을 열면 현재 프로젝트 폴더에서 바로 CLI 명령어를 실행할 수 있습니다. GUI와 CLI를 동시에 사용하는 것이 가장 효율적입니다.
01부 · 기초편
03

3장: Git의 원리

Git이 파일을 어떻게 추적하는지 핵심 원리를 배웁니다. 세 가지 영역의 흐름을 이해하고, status·add·commit·log 명령어로 버전을 쌓는 전 과정을 CLI와 VS Code 두 가지 방법으로 실습합니다.

세 가지 영역git statusgit addgit commitgit logStaging Area
🔗 3장 실습 링크 — Git 원리 & 커밋

3.1 Git의 세 가지 영역과 Git의 흐름

Git을 제대로 이해하려면 세 가지 영역의 개념을 머릿속에 완전히 새겨야 합니다. 이 세 영역 사이를 파일이 이동하며 버전이 기록됩니다.

┌────────────────────────────────────────────────────────────────────┐
│                        Git의 세 가지 영역                           │
├─────────────────┬──────────────────────┬───────────────────────────┤
│  작업 디렉터리   │    스테이징 영역      │       Git 저장소           │
│ Working Dir     │  (Index/Stage)       │    (Repository)           │
│                 │                      │                           │
│  파일을 실제로   │  다음 커밋에 포함할  │  커밋이 쌓이는            │
│  편집하는 공간  │  파일을 모아두는 곳  │  영구 데이터베이스         │
│                 │                      │                           │
│  Untracked      │                      │                           │
│  Modified   ──git add──▶  Staged  ──git commit──▶  Committed      │
│  Deleted        │                      │                           │
└─────────────────┴──────────────────────┴───────────────────────────┘
      ↑ git restore                git restore --staged ↑
영역다른 이름역할파일 상태
작업 디렉터리Working Tree, Working Dir실제 파일이 존재하고 편집이 이루어지는 공간Untracked, Modified
스테이징 영역Index, Stage, Cache커밋할 파일을 선별해 담아두는 준비 공간. "사진을 찍을 피사체를 모으는 공간"Staged
Git 저장소Local Repository, .git커밋이 완료되어 이력이 영구 저장되는 곳Committed
ℹ️
왜 스테이징 영역이 필요할까요?
스테이징 영역 덕분에 수십 개 파일을 수정했더라도, 커밋에 포함할 파일을 선택적으로 고를 수 있습니다. 예를 들어 10개 파일을 수정했을 때, 기능 A 관련 3개 파일만 선택해 커밋하고, 기능 B 관련 파일은 다음 커밋에 담을 수 있습니다. 이렇게 논리적으로 연관된 변경 사항을 하나의 커밋으로 묶어야 이력이 의미 있어집니다.

3.2 Git이 차곡차곡 쌓아둔 상자 — 커밋(Commit)

커밋은 "특정 시점의 프로젝트 전체 스냅샷"입니다. 사진을 찍는 것과 같습니다. 각 커밋에는 다음 정보가 포함됩니다:

  Commit A           Commit B           Commit C
┌──────────┐       ┌──────────┐       ┌──────────┐
│hash: a1b2│       │hash: c3d4│       │hash: e5f6│
│parent: - │◀──── │parent:a1b2◀────  │parent:c3d4
│"초기 설정"│       │"로그인 추가"│      │"버그 수정" │
│author:홍 │       │author:홍 │       │author:김 │
└──────────┘       └──────────┘       └──────────┘
     ↑ 가장 오래된 커밋                    ↑ HEAD (최신)
🔑
커밋 해시(Commit Hash)의 특성
커밋 해시는 a1b2c3d4e5f6789012345678901234567890abcd 형태의 40자리 문자열입니다. 커밋 내용, 타임스탬프, 부모 커밋 해시를 조합해 생성하므로 내용이 조금이라도 다르면 완전히 다른 해시가 나옵니다. 명령어에서는 앞 7자리(a1b2c3d)만 입력해도 Git이 자동으로 찾아줍니다.

3.3 내 프로젝트에서 커밋해보기 — CLI

실제로 파일을 만들고 첫 번째 커밋을 해봅시다. 아래 예제는 간단한 웹 프로젝트를 가정합니다.

3.3.1 git status — 현재 상황 확인

git status는 Git에게 "지금 어떤 상태야?"라고 묻는 명령어입니다. Git을 사용하는 동안 가장 빈번하게 사용하게 될 명령어로, 무언가 하기 전후에 항상 실행하는 습관을 들이세요.

git status 상태별 출력bash
# 파일 하나 생성 $ echo "<h1>Hello Git</h1>" > index.html # 상태 확인 → Untracked 상태 $ git status On branch main No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) index.html ← 빨간색으로 표시됨 nothing added to commit but untracked files present # 파일을 스테이징에 추가한 후 $ git add index.html $ git status On branch main No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: index.html ← 초록색으로 표시됨
상태의미색상
UntrackedGit이 한 번도 추적하지 않은 새 파일빨간색
ModifiedGit이 알고 있는 파일이 수정됨빨간색
Staged스테이징 영역에 추가됨 (커밋 준비 완료)초록색
Committed커밋 완료. git status에 나타나지 않음
3.3.2 git add — 스테이징 영역에 추가하기

git add는 변경 사항을 스테이징 영역으로 이동시킵니다. 커밋에 포함할 파일을 "예약"하는 과정입니다.

git add 다양한 사용법bash
# 특정 파일 한 개만 스테이징 $ git add index.html # 특정 폴더 전체 스테이징 $ git add src/ # 현재 디렉터리의 모든 변경 파일 스테이징 (가장 많이 사용) $ git add . # 특정 확장자만 스테이징 $ git add *.html # 변경된 파일만 (새 파일 제외) $ git add -u # 인터랙티브 스테이징 (파일 내 일부 변경만 선택) $ git add -p index.html # 스테이징 취소 (작업 파일은 그대로) $ git restore --staged index.html
⚠️
git add . 사용 시 주의사항
git add .는 편리하지만, 의도치 않은 파일(예: 개인 설정 파일, 비밀키, 대용량 파일)이 포함될 수 있습니다. .gitignore 파일로 제외할 파일을 미리 설정해두면 안전합니다.
3.3.3 git commit — 변경 사항 기록하기

git commit은 스테이징 영역의 내용을 Git 저장소에 영구적으로 기록합니다. 커밋은 되돌릴 수 있지만(reset/revert), 저장소에 기록된다는 점에서 중요한 행위입니다.

git commit 사용법bash
# 기본: -m 옵션으로 인라인 메시지 입력 (가장 많이 사용) $ git commit -m "feat: HTML 기본 구조 작성" [main (root-commit) a1b2c3d] feat: HTML 기본 구조 작성 1 file changed, 1 insertion(+) create mode 100644 index.html # 스테이징 + 커밋을 한 번에 (이미 tracked 파일만 가능) $ git commit -am "fix: 타이포 수정" # 에디터를 열어 더 긴 메시지 작성 $ git commit # VS Code 또는 설정한 에디터가 열리고, 저장 후 닫으면 커밋됨 # 커밋 결과 출력 해석 [main a1b2c3d] ← 브랜치명, 커밋 해시 앞 7자리 2 files changed, 30 insertions(+), 5 deletions(-) create mode 100644 style.css ← 새로 생성된 파일 delete mode 100644 old.css ← 삭제된 파일
3.3.4 git log — 커밋 메시지 확인

git log는 커밋 이력을 최신순으로 표시합니다. 다양한 옵션으로 보기 편한 형태로 출력할 수 있습니다.

git log 다양한 형태bash
# 기본 출력 (q 키로 종료) $ git log commit e5f6g7h8i9j0... (HEAD -> main) Author: 홍길동 <hong@example.com> Date: Sat Apr 4 10:30:00 2026 +0900 feat: CSS 스타일 추가 commit a1b2c3d4e5f6... Author: 홍길동 <hong@example.com> Date: Sat Apr 4 10:00:00 2026 +0900 feat: HTML 기본 구조 작성 # 한 줄로 간략히 (가장 많이 사용) $ git log --oneline e5f6g7h (HEAD -> main) feat: CSS 스타일 추가 a1b2c3d feat: HTML 기본 구조 작성 # 브랜치 그래프와 함께 $ git log --oneline --graph --all * e5f6g7h (HEAD -> main) feat: CSS 스타일 추가 * a1b2c3d feat: HTML 기본 구조 작성 # 최근 N개만 보기 $ git log -3 # 특정 파일의 변경 이력 $ git log --follow index.html # 특정 날짜 이후 커밋만 $ git log --after="2026-01-01"

3.4 내 프로젝트에서 커밋해보기 — VS Code

3.4.1~3.4.3 status · add · commit — VS Code에서

VS Code의 소스 제어(Source Control) 패널이 CLI의 git status 역할을 합니다. 변경된 파일이 자동으로 목록에 나타납니다.

  • 스테이징(git add): 파일 옆 + 버튼 클릭. 또는 "변경 사항" 섹션 제목 옆 +를 클릭하면 전체 스테이징(git add .).
  • 커밋(git commit): 상단 입력창에 메시지 입력 → Ctrl+Enter(또는 체크 버튼). -m 옵션 없이 인라인으로 커밋됩니다.
  • 언스테이징(git restore --staged): "스테이징된 변경 사항" 섹션에서 파일 옆 - 버튼 클릭.
3.4.4~3.4.5 커밋 메시지 확인 — 내장 터미널과 Git Graph

VS Code 내장 터미널에서 git log --oneline을 실행하거나, Git Graph 확장을 설치하면 브랜치 히스토리를 아름다운 시각적 그래프로 볼 수 있습니다.

💡
Git Graph 사용법
좌측 소스 제어 패널 하단의 "Git Graph" 버튼을 클릭하거나, 명령 팔레트(Ctrl+Shift+P)에서 "Git Graph: View Git Graph"를 검색합니다. 각 커밋을 클릭하면 상세 변경 내용과 diff를 확인할 수 있습니다.
01부 · 기초편
04

4장: 복잡한 문제를 해결하는 브랜치

브랜치는 Git의 핵심 중의 핵심입니다. 독립적인 작업 공간을 만들고, 병합하고, 충돌을 해결하는 방법을 깊이 이해합니다. 실무에서 팀이 실제로 사용하는 Git Flow, GitHub Flow 전략도 함께 배웁니다.

git branchgit switchgit mergeHEAD충돌 해결Git Flow
🔗 4장 실습 링크 — 브랜치 & 병합

4.1 브랜치로 복잡한 문제를 해결하다

브랜치(Branch)는 "평행 우주"입니다. 현재 코드를 건드리지 않고 별도의 작업 공간에서 새로운 기능을 개발할 수 있습니다. 실패해도 원본은 안전합니다. 완성되면 원본에 합칩니다.

🌿 브랜치가 해결하는 문제들
  • 기능 개발 격리: 로그인 기능을 개발하는 동안 메인 코드는 항상 배포 가능한 상태를 유지합니다.
  • 병렬 개발: A팀은 결제 기능, B팀은 검색 기능을 동시에 각자의 브랜치에서 개발합니다.
  • 실험적 시도: "이 방향으로 해볼까?" 싶으면 브랜치를 만들어 시도합니다. 안 되면 브랜치 삭제, 됐으면 병합.
  • 긴급 버그 수정: 배포된 코드에서 버그 발생 시, 현재 개발 중인 코드와 분리해 hotfix 브랜치에서 빠르게 수정합니다.
main ●────────────●────────────────────────────●── (항상 배포 가능) ↘ ↗ merge ↗ merge feature ●────●────● │ hotfix ────────────────────────────────●────●────●

4.2 Git 브랜치를 가리키는 HEAD

HEAD는 "내가 지금 어디에 있는가?"를 나타내는 특수 포인터입니다. 일반적으로 현재 체크아웃된 브랜치의 최신 커밋을 가리킵니다.

                               HEAD
                                ↓
main    ●────●────●────●────●  (HEAD → main → 최신 커밋)
                       ↑
feature ────────────────────●────●  (feature 브랜치)

브랜치 전환(git switch feature) 후:
                                        HEAD
                                         ↓
main    ●────●────●────●────●           
                       ↑         
feature ────────────────────●────●  (HEAD → feature → 최신 커밋)
Detached HEAD
브랜치가 아닌 특정 커밋을 직접 체크아웃하면 HEAD가 브랜치를 통하지 않고 커밋을 직접 가리키는 "Detached HEAD" 상태가 됩니다. 이 상태에서 커밋해도 브랜치에 연결되지 않아 나중에 찾기 어려울 수 있습니다. 반드시 브랜치를 만들거나 기존 브랜치로 이동하세요.

4.3 브랜치를 자유자재로 다루기 — CLI

4.3.1 초기 커밋 만들기
실습 준비 — 초기 커밋bash
$ mkdir branch-practice && cd branch-practice $ git init $ echo "# My Project" > README.md $ git add . $ git commit -m "init: 프로젝트 초기화" [main (root-commit) a1b2c3d] init: 프로젝트 초기화
4.3.2 git branch <브랜치명> — 브랜치 생성하기
브랜치 생성bash
# 브랜치 생성 (생성만 하고 이동하지 않음) $ git branch feature/login # 현재 HEAD는 여전히 main feature/login ← 새로 만든 브랜치 * main ← * 표시 = 현재 위치(HEAD)
ℹ️
브랜치 이름 규칙
브랜치 이름에는 / _ -를 사용할 수 있습니다. feature/login, fix/header-bug, hotfix/payment-crash처럼 슬래시로 계층을 나타내는 것이 관례입니다. 공백, 특수문자, 마침표로 시작하는 이름은 사용할 수 없습니다.
4.3.3 git branch — 모든 브랜치 확인
브랜치 목록 확인bash
# 로컬 브랜치 목록 $ git branch feature/login * main # 마지막 커밋 메시지와 함께 표시 $ git branch -v feature/login a1b2c3d init: 프로젝트 초기화 * main a1b2c3d init: 프로젝트 초기화
4.3.4 git switch — 브랜치 전환하기(HEAD 이동)
브랜치 전환bash
# feature/login 브랜치로 이동 $ git switch feature/login Switched to branch 'feature/login' # HEAD가 이동했는지 확인 $ git branch * feature/login ← 현재 위치 main # 작업 후 커밋 $ echo "로그인 기능" > login.html $ git add . $ git commit -m "feat: 로그인 페이지 추가"
4.3.5 git log --oneline — 커밋 내역 간략하게 보기
각 브랜치의 커밋 이력 비교bash
# feature/login 브랜치의 이력 $ git log --oneline b2c3d4e (HEAD -> feature/login) feat: 로그인 페이지 추가 a1b2c3d (main) init: 프로젝트 초기화 # 모든 브랜치 이력을 그래프로 $ git log --oneline --graph --all * b2c3d4e (HEAD -> feature/login) feat: 로그인 페이지 추가 * a1b2c3d (main) init: 프로젝트 초기화
4.3.6 git switch -c — 브랜치를 생성하고 전환하기

브랜치 생성(git branch)과 전환(git switch)을 한 번에 하는 가장 많이 쓰이는 방법입니다.

생성과 동시에 전환bash
# 브랜치 생성 + 즉시 전환 (-c = --create) $ git switch -c feature/signup Switched to a new branch 'feature/signup' # 구버전 명령어 (checkout -b)도 같은 역할 $ git checkout -b feature/signup
4.3.7 git merge <병합할 브랜치명> — 병합하기

병합(Merge)은 다른 브랜치의 변경 사항을 현재 브랜치로 가져오는 작업입니다. 두 가지 병합 방식이 있습니다.

방식언제 발생특징
Fast-forward대상 브랜치가 현재 브랜치에서 분기된 뒤 현재 브랜치에 변경이 없을 때병합 커밋 없이 포인터만 이동. 이력이 선형으로 유지됨
3-way merge두 브랜치 모두 새 커밋이 있을 때병합 커밋(Merge commit)이 생성됨. 두 줄기가 합쳐진 이력
병합 전체 흐름bash
# 1. main 브랜치로 이동 (병합받을 브랜치) $ git switch main # 2. feature/login을 main에 병합 $ git merge feature/login Updating a1b2c3d..b2c3d4e Fast-forward ← Fast-forward 방식으로 병합됨 login.html | 1 + 1 file changed, 1 insertion(+) create mode 100644 login.html # 3. 병합 완료 후 feature 브랜치 삭제 (선택사항) $ git branch -d feature/login Deleted branch feature/login (was b2c3d4e).
4.3.8 충돌(Conflict) 해결하기

두 브랜치에서 같은 파일의 같은 줄을 다르게 수정했을 때 충돌이 발생합니다. Git은 자동 병합을 포기하고 사용자에게 결정을 맡깁니다. 충돌은 당황스럽지만, 해결 방법은 정해져 있습니다.

충돌 발생 및 해결bash
# 충돌 발생 시 Git 메시지 $ git merge feature/login Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. # 충돌 파일 확인 $ git status On branch main You have unmerged paths. (fix conflicts and run "git commit") Unmerged paths: both modified: index.html # 충돌 파일 내용 (에디터로 열면) <<<<<<< HEAD <title>내 프로젝트</title> ======= <title>My Project</title> >>>>>>> feature/login # 원하는 내용으로 편집 후 충돌 마커 제거 # 예: 두 내용을 합치기 <title>내 프로젝트 (My Project)</title> # 해결 후 스테이징 + 커밋 $ git add index.html $ git commit -m "merge: feature/login 병합 및 title 충돌 해결"
💡
충돌 마커 해석
<<<<<<< HEAD: 현재 브랜치(main)의 내용 | =======: 구분선 | >>>>>>> feature/login: 병합하려는 브랜치의 내용. 이 세 줄의 마커와 내용 중 원하지 않는 것을 삭제하고, 원하는 내용만 남기면 됩니다. VS Code는 "현재 변경 사항 수락", "수신 변경 사항 수락" 버튼을 제공해 클릭 한 번으로 선택할 수 있습니다.

4.4 브랜치를 자유자재로 다루기 — VS Code

VS Code에서는 상태 표시줄(하단) 좌측의 브랜치 이름을 클릭하면 브랜치 목록이 나타나 쉽게 전환할 수 있습니다. 충돌 발생 시 VS Code는 시각적 충돌 해결 UI를 제공합니다.

4.4.1 충돌 해결하기 — VS Code UI
  • 현재 변경 사항 수락: HEAD(현재 브랜치) 내용을 선택
  • 수신 변경 사항 수락: 병합할 브랜치 내용을 선택
  • 두 변경 사항 모두 수락: 두 내용을 모두 합침
  • 변경 사항 비교: diff 뷰에서 나란히 비교 가능

4.5 Git 브랜치 전략

브랜치 전략은 팀이 브랜치를 어떻게 명명하고, 어떤 규칙으로 생성·병합할지 정하는 협업 규약입니다. 전략 없이 각자 자유롭게 브랜치를 만들면 혼돈이 생깁니다.

4.5.1 Git 플로우 전략 (Git Flow)

Vincent Driessen이 2010년에 제안한 전략으로, 5가지 브랜치를 엄격하게 구분합니다. 정해진 배포 일정이 있는 제품(앱 스토어 앱, 패키지 소프트웨어)에 적합합니다.

브랜치역할분기 출발병합 대상
main프로덕션 배포 버전. 항상 안정적
develop다음 릴리즈를 위한 개발 통합 브랜치main
feature/*개별 기능 개발developdevelop
release/*배포 전 QA, 버전 번호 지정developmain + develop
hotfix/*프로덕션 긴급 버그 수정mainmain + develop
4.5.2 깃허브 플로우 전략 (GitHub Flow)

GitHub이 내부적으로 사용하는 단순한 전략입니다. main은 항상 배포 가능한 상태이며, 모든 작업은 feature 브랜치에서 PR을 거쳐 main에 병합됩니다.

main에서 분기
feature 작업
push
PR 생성
코드리뷰
main 병합 + 배포
ℹ️
어떤 전략을 선택해야 할까요?
Git Flow: 배포 일정이 명확한 대형 프로젝트, iOS/Android 앱. GitHub Flow: 지속적 배포(CI/CD)가 갖춰진 웹 서비스, 빠른 이터레이션. 대부분의 스타트업과 웹 서비스는 단순한 GitHub Flow를 선택합니다.
01부 · 기초편
05

5장: 진짜 협업의 시작 깃허브

로컬에만 있던 Git 저장소를 GitHub 원격 서버에 연결합니다. push·pull·fetch·clone의 차이를 명확히 이해하고, Pull Request로 코드를 리뷰하는 협업 워크플로우를 완성합니다.

git pushgit pullgit fetchgit clonegit remotePull Request
🔗 5장 실습 링크 — GitHub & Pull Request

5.1 왜 깃허브를 써야 할까?

Git만으로는 내 컴퓨터에서만 버전 관리가 됩니다. GitHub는 Git 저장소를 인터넷 서버에 호스팅하는 플랫폼으로, 팀 협업의 허브 역할을 합니다.

🌐 GitHub가 제공하는 것
  • 원격 저장소: 코드를 클라우드에 백업하고 팀원과 공유합니다.
  • Pull Request: 코드 리뷰와 토론을 체계적으로 진행합니다.
  • Issues: 버그, 기능 요청, 작업을 이슈로 추적합니다.
  • GitHub Actions: 코드 push 시 자동으로 테스트, 빌드, 배포를 실행합니다.
  • GitHub Pages: 정적 웹사이트를 무료로 호스팅합니다.
  • 오픈소스 생태계: 수백만 개의 오픈소스 프로젝트에 접근하고 기여할 수 있습니다.

5.2 깃허브를 활용한 작업 프로세스

5.2.1 git push — 로컬 변경 사항을 깃허브에 올리기

git push는 로컬 저장소의 커밋을 원격 저장소로 업로드합니다. 인터넷 저장소에 "내 작업을 올리는" 행위입니다.

git push 사용법bash
# 처음 push할 때: upstream 설정 (-u = --set-upstream) $ git push -u origin main Enumerating objects: 3, done. Counting objects: 100% (3/3), done. Writing objects: 100% (3/3), 250 bytes | 250.00 KiB/s, done. Branch 'main' set up to track remote branch 'main' from 'origin'. # 이후에는 간단히 (upstream이 설정되어 있으므로) $ git push # feature 브랜치 push $ git push -u origin feature/login # 강제 push (주의! 팀에서는 금지) $ git push --force
🚨
git push --force 는 팀 작업에서 절대 금지!
--force는 원격 저장소의 이력을 강제로 덮어씁니다. 팀원이 이미 pull한 이력과 충돌이 생겨 심각한 사고로 이어질 수 있습니다. 혼자 작업하는 개인 브랜치가 아니라면 절대 사용하지 마세요.
5.2.2 git pull — 깃허브의 변경 사항을 로컬로 가져오기

git pull은 원격 저장소의 최신 변경 사항을 로컬로 가져와 현재 브랜치에 자동으로 병합합니다. git fetch + git merge를 합친 것과 같습니다.

git pull vs git fetchbash
# git pull = fetch + merge (변경 즉시 반영) $ git pull remote: Enumerating objects: 5, done. Updating a1b2c3d..e5f6g7h Fast-forward README.md | 5 +++++ # git fetch = 가져오기만 (병합 안 함. 내용 확인 후 결정) $ git fetch origin remote: Enumerating objects: 5, done. From https://github.com/user/repo a1b2c3d..e5f6g7h main -> origin/main # fetch 후 무엇이 바뀌었는지 확인 $ git log --oneline main..origin/main e5f6g7h docs: README 업데이트 # 확인 후 병합 $ git merge origin/main
ℹ️
pull vs fetch 언제 무엇을 쓸까?
git pull: 믿을 수 있는 브랜치(main, develop)에서 최신 코드를 바로 받을 때. git fetch: 무엇이 바뀌었는지 먼저 확인한 뒤 병합할지 결정하고 싶을 때. 팀 협업에서는 fetch → 확인 → merge 순서가 더 안전합니다.

5.3 깃허브 계정 생성 및 연결

5.3.1 내 프로젝트를 깃허브와 연결하기
  1. GitHub에서 새 저장소 생성
    github.com 우측 상단 + 버튼 → New repository. 저장소 이름 입력, 공개/비공개 선택. README 추가 체크를 하지 마세요 — 로컬에 이미 파일이 있으면 충돌이 생깁니다.
  2. 생성된 HTTPS URL 복사
    https://github.com/아이디/저장소명.git 형태의 URL을 복사합니다.
  3. 로컬에서 원격 저장소 연결
    복사한 URL로 git remote add 실행.
5.3.2 git remote — 현재 연결된 원격 저장소 확인
원격 저장소 관리bash
# 원격 저장소 목록 $ git remote origin # URL 포함 상세 보기 $ git remote -v origin https://github.com/hong/my-project.git (fetch) origin https://github.com/hong/my-project.git (push)
5.3.3 git remote add — 원격 저장소 추가하기
원격 저장소 추가·변경·삭제bash
# 원격 저장소 추가 (origin이 관례적 이름) $ git remote add origin https://github.com/hong/my-project.git # URL 변경 (저장소를 옮겼을 때) $ git remote set-url origin https://github.com/hong/new-repo.git # 원격 저장소 삭제 (연결만 끊는 것. GitHub에서 삭제되진 않음) $ git remote remove origin
ℹ️
origin이란?
origin은 원격 저장소의 별명(alias)입니다. 관례적으로 기본 원격 저장소를 origin이라 부릅니다. 오픈소스에 기여할 때는 원본 저장소를 upstream이라 부르기도 합니다.
5.3.4 git clone — 원격 저장소를 로컬에 복제하기

기존 저장소에 팀원으로 합류하거나, 오픈소스를 내려받을 때 사용합니다. clone은 저장소 전체 이력을 내려받고 origin remote를 자동으로 설정합니다.

git clone 사용법bash
# 기본 clone (폴더명 = 저장소명) $ git clone https://github.com/user/project.git Cloning into 'project'... remote: Enumerating objects: 100, done. Receiving objects: 100% (100/100), 1.2 MiB | 5.0 MiB/s, done. # 폴더명 지정 $ git clone https://github.com/user/project.git my-folder # 특정 브랜치만 clone $ git clone -b develop https://github.com/user/project.git # clone 후 remote 자동 설정 확인 $ cd project && git remote -v origin https://github.com/user/project.git (fetch) origin https://github.com/user/project.git (push)

5.4 깃허브 활용 실습

실제 팀 협업 시나리오를 따라가며 push·fetch·pull 전체 흐름을 실습합니다.

5.4.1 git push — 첫 push
첫 번째 push 전체 흐름bash
# 1. 로컬에서 작업 후 커밋 $ git add . && git commit -m "feat: 메인 페이지 완성" # 2. 원격에 push (-u로 upstream 설정) $ git push -u origin main # 이후 커밋은 바로 push 가능 $ git push
5.4.2 git fetch — 변경 사항 미리 확인하기
fetch 후 diff 확인bash
# 원격의 변경 사항 가져오기 (병합 없음) $ git fetch origin # 원격 main과 로컬 main 차이 확인 $ git diff main origin/main # 원격에서 새로 추가된 커밋 목록 $ git log --oneline main..origin/main
5.4.3 git pull — 가져오고 병합하기
pull 시 충돌 상황bash
# 팀원이 push한 내용 받아오기 $ git pull # 로컬에도 수정 사항이 있으면 충돌 가능 Auto-merging README.md CONFLICT (content): Merge conflict in README.md # 충돌 해결 후 커밋 (이전 4.3.8 참고) $ git add . && git commit

5.5 풀 리퀘스트(PR)로 탄탄하게 협업하기

PR(Pull Request)은 "내 브랜치를 메인에 합쳐주세요"라는 요청입니다. 단순 병합이 아니라, 코드를 팀원에게 공유하고 리뷰를 받는 과정입니다. 좋은 팀은 PR 없이 아무것도 main에 직접 push하지 않습니다.

5.5.1 PR 과정을 포함한 전체 협업 흐름
  1. feature 브랜치 생성 및 작업
    git switch -c feature/검색기능 → 개발 → git add . && git commit
  2. 원격 저장소에 push
    git push -u origin feature/검색기능
  3. GitHub에서 PR 생성
    GitHub 웹페이지에 "Compare & pull request" 버튼 클릭. base: main ← compare: feature/검색기능 설정.
  4. PR 작성
    제목, 설명(무엇을 왜 했는지), 스크린샷, 테스트 방법 등을 작성합니다.
  5. 코드 리뷰
    팀원이 코드 라인별로 코멘트를 남깁니다. 수정 요청이 오면 로컬에서 수정 후 같은 브랜치에 push하면 PR에 자동 반영됩니다.
  6. Approve 후 병합
    Approve를 받으면 "Merge pull request" 버튼으로 main에 병합합니다.
  7. 로컬 정리
    git switch main && git pull로 최신 main을 받고, git branch -d feature/검색기능으로 로컬 feature 브랜치 정리.
5.5.2 풀 리퀘스트 생성 — 변경 사항 공유 및 제안

좋은 PR은 리뷰어가 맥락을 빠르게 파악할 수 있도록 작성합니다. GitHub은 PR 템플릿(.github/pull_request_template.md)을 지원합니다.

PR 템플릿 예시 (.github/pull_request_template.md)markdown
## 개요 이 PR이 해결하는 문제 또는 구현하는 기능을 설명합니다. 관련 이슈: closes #123 ## 변경 사항 - [ ] 검색 API 연동 - [ ] 검색 결과 UI 구현 - [ ] 유닛 테스트 추가 ## 테스트 방법 1. /search?q=테스트 로 접속 2. 결과가 정상 표시되는지 확인 ## 스크린샷 (필요한 경우 스크린샷 첨부)

5.6 커밋과 PR을 효과적으로 작성하기

5.6.1 효과적으로 커밋 메시지 작성하기

커밋 메시지는 코드 변경 이유를 미래의 나와 팀원에게 전달하는 문서입니다. Conventional Commits 규약을 따르면 자동화 도구(changelog 생성, 버전 관리)와도 호환됩니다.

타입의미예시
feat새로운 기능 추가feat: 카카오 로그인 추가
fix버그 수정fix: 결제 금액 오류 수정
docs문서 변경docs: README 설치 방법 업데이트
style포맷, 세미콜론 등 (기능 변경 없음)style: 들여쓰기 통일
refactor리팩터링 (버그 수정·기능 추가 아님)refactor: 인증 로직 분리
test테스트 추가·수정test: 로그인 API 단위 테스트 추가
chore빌드, 패키지 관리 등 기타chore: ESLint 설정 추가
perf성능 개선perf: 이미지 지연 로딩 적용
좋은 커밋 메시지 vs 나쁜 커밋 메시지bash
# ✅ 좋은 예: 타입 + 명확한 내용 feat: 회원가입 이메일 인증 기능 추가 (#45) fix: iOS Safari에서 모달이 닫히지 않는 버그 수정 perf: 메인 페이지 LCP 3.2s → 1.4s 개선 # ❌ 나쁜 예: 무엇을 했는지 알 수 없음 수정 update ㅇㅇ asdfgh
5.6.2 효과적으로 PR 작성하기
  • 작은 PR 유지: 하나의 PR은 하나의 기능 또는 버그 수정만 담습니다. 리뷰하기 쉽고, 문제 발생 시 롤백도 쉽습니다.
  • 이슈 연결: closes #45를 PR 본문에 쓰면 병합 시 해당 이슈가 자동으로 닫힙니다.
  • self-review 먼저: 팀원에게 보내기 전에 내 PR의 diff를 직접 한 번 읽어보세요. 오타나 실수를 미리 발견할 수 있습니다.
  • 리뷰어 지정: Reviewers 섹션에서 리뷰를 요청할 팀원을 지정합니다.
02부 · 실전편
06

6장: 오픈소스에 기여하기 — 명언 백과사전

Fork → Clone → Branch → Commit → PR의 오픈소스 기여 전체 흐름을 실제 프로젝트에서 경험합니다. 오픈소스에 처음 기여하는 분들을 위한 완벽 가이드입니다.

Forkupstream오픈소스 기여PRContributor
🔗 6장 실습 링크 — 오픈소스 기여

6.1 명언 백과사전이란?

명언 백과사전(Quotes Encyclopedia)은 오픈소스 기여 입문을 위해 설계된 실습 프로젝트입니다. 참여자 각자가 마크다운 파일에 자신이 좋아하는 명언을 작성해 PR로 기여합니다. 코드가 아닌 내용을 기여하므로, 프로그래밍 실력과 무관하게 누구나 실제 PR 과정을 경험할 수 있습니다.

🔄 오픈소스 기여 vs 일반 협업의 차이
  • 권한이 없습니다: 원본 저장소에 직접 push할 수 없습니다. 반드시 Fork → PR 과정을 거칩니다.
  • 메인테이너 승인: 프로젝트 관리자(메인테이너)가 PR을 검토하고 병합합니다.
  • 기여자로 기록됩니다: 병합되면 GitHub Contributors 목록에 이름이 올라갑니다.

6.2 프로젝트 포크(Fork)

Fork는 타인의 GitHub 저장소를 내 GitHub 계정으로 복사하는 것입니다. 이 복사본은 완전히 내 소유이므로 자유롭게 수정할 수 있습니다.

  원본 저장소                    내 Fork
  original/quotes   ─── Fork ──▶  내아이디/quotes
       │                               │
       │                          로컬 Clone
       │                               ↓
       │                         내 컴퓨터 (로컬)
       │                               │
       └──── PR (병합 요청) ────────────┘
  1. GitHub에서 Fork 버튼 클릭
    원본 저장소 페이지 우측 상단의 Fork 버튼 클릭 → "Create a new fork" → 내 계정으로 Fork 생성.
  2. Fork된 저장소를 로컬에 Clone
    내 계정의 Fork 저장소 URL을 복사해 clone합니다.
  3. upstream 설정
    원본 저장소를 upstream으로 등록해 최신 변경 사항을 받아올 수 있게 합니다.
Fork 후 로컬 설정bash
# 1. 내 Fork를 clone $ git clone https://github.com/내아이디/quotes.git $ cd quotes # 2. 원본 저장소를 upstream으로 등록 $ git remote add upstream https://github.com/original/quotes.git # 3. 설정 확인 $ git remote -v origin https://github.com/내아이디/quotes.git (fetch) origin https://github.com/내아이디/quotes.git (push) upstream https://github.com/original/quotes.git (fetch) upstream https://github.com/original/quotes.git (push) # 원본 최신화 (다른 기여자들의 변경 사항 받기) $ git fetch upstream $ git merge upstream/main

6.3 프로젝트 브랜치와 파일 만들기

브랜치 생성 및 파일 작성bash
# 내 이름으로 브랜치 생성 $ git switch -c feat/hong-gildong-quote # quotes 폴더에 내 파일 생성 $ touch quotes/hong-gildong.md

6.4 명언 작성과 커밋

명언 파일 작성 및 커밋markdown
# quotes/hong-gildong.md 내용 # 홍길동의 명언 > "하늘은 스스로 돕는 자를 돕는다." — 기여자: 홍길동 — 날짜: 2026-04-04
커밋 및 pushbash
$ git add quotes/hong-gildong.md $ git commit -m "feat: 홍길동 명언 추가" $ git push -u origin feat/hong-gildong-quote

6.5 풀 리퀘스트를 생성하고 프로젝트에 기여하기

push 후 GitHub에서 내 Fork를 열면 "Compare & pull request" 버튼이 나타납니다. 클릭 후 PR을 작성하면 원본 저장소의 메인테이너에게 전달됩니다.

💡
기여 전 반드시 CONTRIBUTING.md를 읽으세요
대부분의 오픈소스 프로젝트는 기여 가이드라인을 CONTRIBUTING.md에 명시합니다. 코딩 스타일, 커밋 메시지 규칙, PR 작성 방법 등을 따르지 않으면 PR이 거절될 수 있습니다.
ℹ️
PR이 병합된 후
병합된 후에는 git switch main → git pull upstream main → git push origin main으로 내 Fork를 최신 상태로 유지합니다. feature 브랜치는 git branch -d로 정리합니다.
02부 · 실전편
07

7장: 실무에서 자주 사용하는 Git 명령어

amend·cherry-pick·stash·reset·revert·rebase·reflog. 처음에는 몰라도 되지만, 실무를 하다 보면 반드시 만나게 되는 명령어들입니다. 각 명령어의 동작 원리와 사용 타이밍을 정확히 이해합니다.

amendcherry-pickstashresetrevertrebasereflog
🔗 7장 실습 링크 — 고급 명령어

7.1 브랜치의 생성·수정·삭제: git branch

4장에서 배운 기본 브랜치 명령어에 더해, 실무에서 자주 쓰는 고급 옵션을 알아봅니다.

7.1.1 git branch -m — 현재 브랜치명 변경
브랜치명 변경bash
# 현재 브랜치의 이름을 변경 (-m = --move) $ git branch -m 새브랜치명 # 다른 브랜치 이름 변경 (현재 위치 무관) $ git branch -m 기존이름 새이름 # 원격에 올라간 브랜치명도 바꾸려면? # 1. 로컬에서 이름 변경 $ git branch -m feature/old-name feature/new-name # 2. 새 이름으로 push $ git push origin -u feature/new-name # 3. 원격에서 기존 이름 삭제 $ git push origin --delete feature/old-name
7.1.2 git branch -d — 브랜치 삭제
브랜치 삭제bash
# 병합된 브랜치 삭제 (안전, 미병합 시 거부됨) $ git branch -d feature/login Deleted branch feature/login (was b2c3d4e). # 강제 삭제 (미병합이어도 삭제, 주의 필요) $ git branch -D feature/abandoned # 원격 브랜치 삭제 (GitHub에서 브랜치 제거) $ git push origin --delete feature/login
7.1.3 git branch -r — 원격 브랜치 목록
7.1.4 git branch -a — 로컬 + 원격 브랜치 모두 보기
브랜치 목록 조회bash
# 원격 브랜치만 보기 $ git branch -r origin/HEAD -> origin/main origin/develop origin/feature/payment # 로컬 + 원격 모두 보기 $ git branch -a * main develop remotes/origin/main remotes/origin/develop

7.2 브랜치 이동과 파일 복원: git checkout · git switch · git restore

7.2.1 git checkout — 이동과 복원을 모두 수행하는 구버전 명령어

git checkout은 브랜치 전환과 파일 복원을 모두 처리하던 과거 명령어입니다. 현재는 두 역할이 git switchgit restore로 분리되었습니다. 그러나 오래된 자료나 레거시 스크립트에서 자주 보이므로 이해해야 합니다.

checkout의 두 역할bash
# 브랜치 전환 (현재는 git switch 권장) $ git checkout develop $ git checkout -b feature/new # 브랜치 생성+전환 # 파일 복원 (현재는 git restore 권장) $ git checkout -- index.html # 수정 내용 버리고 마지막 커밋 상태로 # 특정 커밋 시점의 파일 복원 $ git checkout a1b2c3d -- index.html
7.2.2 git switch — 브랜치 전환하기 (권장)

git switch는 Git 2.23부터 도입된 명확한 브랜치 전환 전용 명령어입니다.

git switch 상세 사용법bash
# 브랜치 전환 $ git switch develop # 브랜치 생성 + 전환 $ git switch -c feature/search # 이전 브랜치로 돌아가기 (- 는 이전 브랜치) $ git switch - # 원격 브랜치를 추적하는 로컬 브랜치 생성 $ git switch -c feature/pay origin/feature/pay
7.2.3 git restore — 작업 파일 복원하기 (권장)

git restore는 파일을 이전 상태로 복원하는 전용 명령어입니다.

git restore 사용법bash
# 작업 디렉터리의 변경 취소 (마지막 커밋 상태로 복원) $ git restore index.html # 모든 변경 취소 $ git restore . # 스테이징 취소 (작업 파일은 그대로) $ git restore --staged index.html # 특정 커밋 시점의 파일로 복원 $ git restore --source=a1b2c3d index.html
🚨
git restore 는 되돌릴 수 없습니다
git restore index.html을 실행하면 스테이징하지 않은 변경 사항이 영구적으로 삭제됩니다. 커밋하지 않은 변경 사항은 복구가 불가능하므로 신중하게 사용하세요.

7.3 최신 커밋을 덮어씌우거나 수정하기: git commit --amend

방금 커밋했는데 메시지가 틀렸거나, 파일 하나를 빠뜨렸을 때 사용합니다. 새 커밋을 만드는 게 아니라 마지막 커밋을 교체합니다.

7.3.1 아무런 수정사항 없이 저장하기
amend 다양한 사용법bash
# 커밋 메시지만 수정 (에디터 열림) $ git commit --amend # 7.3.2: 메시지를 인라인으로 수정 $ git commit --amend -m "feat: 로그인 기능 구현 (수정)" # 7.3.3: 에디터가 열리면 저장 없이 종료 = amend 취소 # vim: :q! | VS Code: 파일 닫기 # 7.3.4: 빠뜨린 파일 추가 (메시지 유지) $ git add forgotten.js $ git commit --amend --no-edit [main a1b2c3d] feat: 로그인 기능 구현 # 해시가 바뀐 것을 주목! 커밋이 교체된 것임
🚨
push 후 amend는 히스토리 재작성 — 팀에서 금지!
amend는 커밋 해시를 변경합니다. 이미 push된 커밋을 amend하면 로컬과 원격의 이력이 달라져, git push --force를 써야 하고 팀원의 저장소와 충돌이 생깁니다. 반드시 push 전에만 사용하세요.

7.4 특정 커밋만 떼내어 가져오기: git cherry-pick

다른 브랜치의 특정 커밋 하나(또는 몇 개)만 현재 브랜치에 적용하고 싶을 때 사용합니다. "커밋을 골라 담는다"는 뜻입니다.

🍒 cherry-pick 실무 사용 예
  • develop 브랜치에서 버그를 수정했는데, 그 수정만 main에도 빠르게 적용해야 할 때
  • 잘못된 브랜치에 커밋했을 때 올바른 브랜치로 가져오기
  • 팀원의 브랜치에서 아직 병합되지 않은 특정 기능만 먼저 사용해야 할 때
cherry-pick 전체 사용법bash
# 단일 커밋 cherry-pick $ git cherry-pick a1b2c3d [main e5f6g7h] feat: 결제 버그 수정 1 file changed, 3 insertions(+), 1 deletion(-) # 여러 커밋 한 번에 $ git cherry-pick a1b2c3d d4e5f6g h7i8j9k # 범위 지정 (a1b2..h7i8의 모든 커밋) $ git cherry-pick a1b2c3d^..h7i8j9k # 7.4.3: 커밋하지 않고 작업 디렉터리에만 적용 $ git cherry-pick --no-commit a1b2c3d # 7.4.1: 충돌 해결 후 이어서 $ git cherry-pick --continue # 7.4.2: cherry-pick 중단 (원래 상태로) $ git cherry-pick --abort

7.5 임시 저장소에 잠깐 두기: git stash

작업 중에 갑자기 다른 일을 처리해야 할 때가 있습니다. 커밋하기엔 완성되지 않았고, 버리기엔 아깝습니다. git stash는 변경 사항을 임시 공간에 보관하고 작업 디렉터리를 깔끔하게 만들어줍니다.

stash 전체 사용법bash
# 기본 stash (메시지 없음) $ git stash Saved working directory and index state WIP on main: a1b2c3d feat: 초기화 # 메시지와 함께 저장 (권장) $ git stash push -m "로그인 폼 작업 중 - UI 완성 80%" # Untracked 파일도 함께 저장 $ git stash -u # 7.5.1: stash 목록 확인 $ git stash list stash@{0}: On main: 로그인 폼 작업 중 - UI 완성 80% stash@{1}: WIP on develop: 검색 기능 반쪽 # 7.5.2: 가장 최근 stash 적용 (stash는 유지) $ git stash apply # 특정 stash 적용 $ git stash apply stash@{1} # 7.5.3: 가장 최근 stash 적용 + 목록에서 제거 (가장 많이 사용) $ git stash pop # 7.5.4: 특정 stash 삭제 $ git stash drop stash@{0} # 모든 stash 삭제 $ git stash clear

7.6 예전 작업 상태로 돌아가기: git reset · git revert

7.6.1 git reset — 커밋을 취소하거나 되돌리기

git reset은 HEAD를 특정 커밋으로 이동시키는 명령어입니다. 세 가지 모드가 있으며, 모드에 따라 스테이징 영역과 작업 디렉터리에 미치는 영향이 다릅니다.

모드커밋 이력스테이징 영역작업 디렉터리사용 상황
--soft되돌림변경 사항 유지(Staged)그대로커밋을 합치고 싶을 때
--mixed되돌림변경 사항 해제(Unstaged)그대로커밋 취소 후 내용 수정
--hard되돌림삭제삭제 ⚠️완전히 없애고 싶을 때
reset 상세 예제bash
# 현재 상태: A → B → C (HEAD) # --soft: C 커밋을 취소하고 내용은 staged 상태로 유지 $ git reset --soft HEAD~1 # 결과: A → B (HEAD). C의 변경사항은 staged에 있음 # --mixed(기본값): C 커밋 취소, 변경사항은 unstaged $ git reset HEAD~1 # 결과: A → B (HEAD). C의 변경사항은 작업 디렉터리에 있음 # --hard: C 커밋 + 변경사항 모두 삭제 (복구 어려움!) $ git reset --hard HEAD~1 # 결과: A → B (HEAD). C는 영구 삭제 # HEAD~N: N개 이전 커밋. HEAD~2 = 2개 이전 # 또는 해시 직접 사용 $ git reset --soft a1b2c3d
7.6.2 git revert — 커밋을 삭제하지 않고 안전하게 되돌리기

특정 커밋을 취소하는 새로운 커밋을 만들어 이력에 추가합니다. 이미 push된 변경 사항을 되돌릴 때 유일하게 안전한 방법입니다.

revert 사용법bash
# A → B → C 에서 B를 revert $ git revert b2c3d4e [main x1y2z3a] Revert "feat: 결제 기능 추가" # 결과: A → B → C → D (D는 B의 내용을 취소하는 커밋) # 에디터 없이 자동 커밋 $ git revert --no-edit b2c3d4e # 커밋 없이 작업 디렉터리에만 반영 $ git revert --no-commit b2c3d4e # 범위 revert $ git revert b2c3d4e^..e5f6g7h
7.6.3 reset vs revert 차이점과 주의사항
항목git resetgit revert
히스토리이력을 삭제·재작성이력을 추가함(취소 커밋 생성)
push 이후 사용위험. force push 필요. 팀 충돌 발생안전. 일반 push로 배포 가능
협업 중 사용개인 브랜치에서만 사용 가능공유 브랜치에서도 사용 가능
복구 방법git reflog로 복구 가능 (90일 내)revert의 revert로 원복 가능
추천 상황push 전, 로컬 커밋 정리push 이후, 프로덕션 긴급 롤백

7.7 Git 히스토리를 합치고 수정하고 삭제하고: git rebase

git rebase는 Git에서 가장 강력하면서 조심스러운 명령어입니다. 브랜치의 기반(base) 커밋을 변경해 이력을 재작성합니다.

7.7.1 병합 기능 — rebase vs merge 차이
[merge 결과] — 병합 커밋이 생성됨
  main    ●────●────●────M   (M = Merge commit)
                ↑       ↑
  feature  ●────●────●──┘

[rebase 결과] — 선형 이력 유지
  main    ●────●────●────●'───●'───●'
          (feature 커밋들이 main 끝에 재작성됨. '는 새 해시)
rebase로 브랜치 병합bash
# feature 브랜치에서: main의 최신 커밋 위로 재작성 $ git switch feature/login $ git rebase main Successfully rebased and updated refs/heads/feature/login. # 충돌 시 해결 후 $ git rebase --continue # rebase 중단 $ git rebase --abort
7.7.2 Interactive Rebase — 히스토리 수정·삭제

git rebase -i는 커밋 이력을 편집하는 강력한 도구입니다. 커밋 합치기, 메시지 수정, 순서 변경, 삭제를 할 수 있습니다.

Interactive Rebasebash
# 최근 3개 커밋을 인터랙티브하게 편집 $ git rebase -i HEAD~3 # 에디터가 열리면 (위에서 아래 순서 = 오래된 → 최신) pick a1b2c3d feat: 검색 UI 추가 pick d4e5f6g feat: 검색 API 연동 pick h7i8j9k fix: 검색 결과 정렬 버그 # 사용 가능한 명령어 (pick → 원하는 명령으로 교체) pick = 그대로 사용 reword = 커밋 메시지만 수정 edit = 커밋 내용 수정 squash = 이전 커밋과 합치기 (메시지도 합침) fixup = 이전 커밋과 합치기 (이 커밋 메시지 버림) drop = 커밋 삭제 # 예: d4e5와 h7i8을 a1b2에 합치기 (squash) pick a1b2c3d feat: 검색 기능 구현 squash d4e5f6g feat: 검색 API 연동 fixup h7i8j9k fix: 검색 결과 정렬 버그 # 저장 후 닫으면 3개가 1개로 합쳐짐
7.7.3 한꺼번에 처리하기 — rebase 실전 워크플로우
💡
PR 전 커밋 정리에 활용
feature 브랜치에서 개발하다 보면 "WIP", "수정", "또 수정" 같은 지저분한 커밋이 쌓입니다. PR을 보내기 전에 git rebase -i로 관련 커밋들을 하나로 합치면 리뷰어가 훨씬 이해하기 쉬운 깔끔한 이력이 만들어집니다.

7.8 Git의 모든 동작이 기록된 곳: git reflog

git reflog는 Git의 블랙박스입니다. git log가 커밋 이력을 보여준다면, reflog는 HEAD가 이동한 모든 기록을 보여줍니다. git reset --hard로 삭제한 커밋도 reflog로 복구할 수 있습니다.

reflog로 실수 복구하기bash
# 실수로 reset --hard로 3개 커밋 삭제 $ git reset --hard HEAD~3 # reflog로 이전 HEAD 위치 확인 $ git reflog a1b2c3d (HEAD -> main) HEAD@{0}: reset: moving to HEAD~3 e5f6g7h HEAD@{1}: commit: feat: 기능 C d4e5f6g HEAD@{2}: commit: feat: 기능 B c3d4e5f HEAD@{3}: commit: feat: 기능 A ← 복구할 위치 # 삭제하기 전 상태로 복구 $ git reset --hard e5f6g7h HEAD is now at e5f6g7h feat: 기능 C # 모든 커밋이 복구되었습니다! # 특정 시점으로 이동 $ git reset --hard HEAD@{2}
ℹ️
reflog 보존 기간 및 한계
reflog는 기본적으로 90일간 보존됩니다. 90일이 지나면 가비지 컬렉션으로 정리됩니다. 또한 reflog는 로컬에만 있습니다. 컴퓨터가 파손되거나 저장소를 새로 clone하면 사라집니다.
03부 · GUI편
08

8장: GUI와 깃허브 데스크톱

명령줄 없이 마우스로 Git을 사용하는 GitHub Desktop을 소개합니다. 설치부터 저장소 생성, 파일 업로드, 원격에서 가져오기까지 GUI 환경의 전체 흐름을 익힙니다.

GitHub DesktopGUI저장소 생성commitpushpull
🔗 8장 실습 링크 — GitHub Desktop 설치 & 기본

8.1 깃허브 데스크톱이란?

GitHub Desktop은 GitHub이 공식 제공하는 무료 GUI(Graphical User Interface) Git 클라이언트입니다. 터미널 명령어 없이 마우스와 버튼만으로 커밋·브랜치·푸시·풀 등 대부분의 Git 작업을 수행할 수 있습니다.

🖥️ GitHub Desktop vs CLI
항목CLI (Terminal)GitHub Desktop
학습 곡선명령어 암기 필요직관적 UI
시각화텍스트 출력브랜치·diff 시각적 표시
속도숙련 후 빠름클릭 필요, 상대적으로 느림
자동화스크립트 가능반복 작업 불편
추천 대상개발자, 자동화 필요Git 입문자, 비개발자 협업자
💡
CLI와 GUI는 함께 사용하는 것이 가장 효율적입니다
복잡한 작업(interactive rebase, reflog 복구 등)은 CLI로, 일상적인 커밋·브랜치 전환은 GitHub Desktop으로 처리하는 혼합 방식이 실무에서 가장 널리 쓰입니다.

8.2 깃허브 데스크톱 설치하기

GitHub Desktop은 Windows와 macOS를 공식 지원합니다. Linux는 비공식 포크 버전을 사용하거나 다른 GUI 클라이언트(GitKraken, Sourcetree)를 사용합니다.

  1. 다운로드
    https://desktop.github.com에 접속해 운영체제에 맞는 설치 파일을 내려받습니다. Windows는 GitHubDesktopSetup-x64.exe, macOS는 GitHubDesktop.zip을 받습니다.
  2. 설치 및 실행
    설치 완료 후 GitHub Desktop을 실행합니다. 자동 업데이트를 지원하므로 최신 버전을 유지하기 쉽습니다.
  3. GitHub 계정 로그인
    Sign in to GitHub.com 버튼 클릭 → 브라우저에서 GitHub 인증 → 인증 완료 후 앱으로 복귀.
  4. 사용자 정보 설정
    커밋에 기록될 이름과 이메일을 확인하고 Finish를 클릭합니다. 이미 CLI에서 설정한 경우 자동으로 불러옵니다.
ℹ️
Git이 설치되어 있지 않아도 됩니다
GitHub Desktop에는 Git이 내장되어 있어, Git을 별도로 설치하지 않아도 사용할 수 있습니다. 단, CLI를 함께 사용할 계획이라면 Git 별도 설치를 권장합니다.

8.3 깃허브 데스크톱 살펴보기

GitHub Desktop의 화면은 크게 세 영역으로 구성됩니다:

┌─────────────────────────────────────────────────────────────────┐
│  [Current Repository ▼]  [Current Branch ▼]  [Fetch/Push/Pull] │  ← 상단 툴바
├─────────────────────┬───────────────────────────────────────────┤
│                     │                                           │
│  변경된 파일 목록    │          Diff 뷰                          │
│  (Changes Tab)      │  (추가된 줄 = 초록, 삭제된 줄 = 빨강)      │
│                     │                                           │
│  ┌────────────────┐ │                                           │
│  │ 커밋 메시지 입력│ │                                           │
│  │ [Commit] 버튼  │ │                                           │
│  └────────────────┘ │                                           │
├─────────────────────┴───────────────────────────────────────────┤
│  History Tab: 커밋 이력 및 각 커밋의 변경 내용 확인              │  ← 하단 탭
└─────────────────────────────────────────────────────────────────┘

8.4 저장소 생성하기 — Create a New Repository

GitHub Desktop에서 새 저장소를 만드는 방법은 두 가지입니다:

방법설명메뉴
새 저장소 생성로컬에 새 폴더 + git init을 자동 실행. GitHub에 게시(Publish) 버튼으로 원격 연결File → New Repository
기존 저장소 추가이미 있는 로컬 저장소를 GitHub Desktop에 등록File → Add Local Repository
CloneGitHub의 원격 저장소를 로컬에 복제File → Clone Repository
  1. File → New Repository
    Name(저장소명), Local Path(저장 폴더), Description(설명), Initialize with README(선택) 입력 → Create Repository 클릭.
  2. GitHub에 게시
    우측 상단 Publish repository 버튼 클릭 → 공개/비공개 선택 → Publish Repository. GitHub에 동명의 저장소가 자동 생성됩니다.

8.5 내 컴퓨터의 파일을 깃허브에 올리기

GitHub Desktop에서 커밋하고 push하는 전체 흐름입니다. CLI의 git add → git commit → git push에 해당합니다.

  1. 파일 수정 또는 생성
    저장소 폴더에서 파일을 편집합니다. 저장하는 순간 GitHub Desktop의 Changes 탭에 자동으로 나타납니다.
  2. 변경 파일 확인 (git status 역할)
    좌측 Changes 탭에서 수정된 파일 목록을 확인합니다. 파일 클릭 시 우측에 diff(변경 내용)가 표시됩니다.
  3. 파일 선택 (git add 역할)
    파일 왼쪽 체크박스를 켜고 끄며 커밋에 포함할 파일을 선택합니다. 기본은 모두 체크됩니다.
  4. 커밋 메시지 작성 (git commit 역할)
    하단 Summary 입력창에 커밋 제목을, Description에 상세 내용을 입력합니다. Summary는 필수입니다.
  5. Commit to main 클릭
    버튼 클릭 시 커밋이 완료됩니다. Changes 탭이 비워지고 History 탭에 새 커밋이 나타납니다.
  6. Push origin (git push 역할)
    상단 Push origin 버튼 클릭. 숫자 뱃지가 표시되면 push할 커밋이 있다는 의미입니다.

8.6 깃허브 파일을 내 컴퓨터에 가져오기

팀원이 원격 저장소에 push한 내용을 내 로컬로 가져오는 방법입니다. CLI의 git pull에 해당합니다.

  1. Fetch origin 클릭
    상단 Fetch origin 버튼 클릭. 원격의 새 커밋 수를 확인합니다(숫자 뱃지 표시).
  2. Pull origin 클릭
    Fetch 후 버튼이 Pull origin으로 바뀝니다. 클릭하면 변경 사항을 로컬에 반영합니다.
  3. 충돌 발생 시
    충돌이 있으면 GitHub Desktop이 알려줍니다. Open in Editor를 클릭해 VS Code에서 충돌을 해결한 뒤 Continue merge를 클릭합니다.
💡
작업 시작 전 항상 Fetch → Pull 먼저
팀 협업에서는 작업을 시작하기 전 반드시 Fetch → Pull로 최신 코드를 받아와야 충돌을 예방할 수 있습니다. 이 습관이 PR 충돌의 90%를 예방합니다.
03부 · GUI편
09

9장: 깃허브 데스크톱으로 협업하기

GitHub Desktop으로 실제 팀 협업 시나리오를 수행합니다. 브랜치 전환, 커밋·PR 생성, 그리고 CLI 명령어와 GitHub Desktop 단축 버튼을 대응하는 레퍼런스까지 정리합니다.

브랜치 협업PR충돌CLI 대응표
🔗 9장 실습 링크 — GitHub Desktop 협업

9.1 변경 사항 가져오기

GitHub Desktop에서 팀원의 최신 작업을 받아오는 전체 과정입니다. 팀 협업의 일상적인 시작 루틴입니다.

9.1.1 현재 저장소 Fetch

작업 시작 전 반드시 Fetch를 실행해 원격의 변경 사항을 확인합니다.

  1. Current Repository 선택
    좌측 상단의 Current Repository 드롭다운에서 작업할 저장소를 선택합니다.
  2. Fetch origin 클릭
    상단 Fetch origin 버튼 클릭. 원격과 동기화해 새 커밋이 있는지 확인합니다. 마지막 fetch 시간도 표시됩니다.
  3. Pull origin (변경 사항 있을 때)
    숫자 뱃지와 함께 Pull origin이 표시되면 클릭해 로컬에 반영합니다.
9.1.2 충돌 해결

Pull 과정에서 충돌이 발생하면 GitHub Desktop이 해당 파일 목록을 표시합니다.

  1. 충돌 파일 확인
    충돌 발생 시 "Conflicts in X files" 메시지와 파일 목록이 나타납니다.
  2. 에디터에서 해결
    Open in Visual Studio Code(또는 설정된 에디터) 버튼 클릭 → 충돌 마커를 수동 편집하거나 VS Code의 충돌 해결 UI 사용.
  3. Continue merge
    충돌 해결 후 파일 저장 → GitHub Desktop에서 Continue merge 버튼 클릭.

9.2 브랜치

GitHub Desktop에서 브랜치를 관리하는 방법입니다. 팀 협업에서는 항상 feature 브랜치를 만들어 작업하고 PR을 거쳐 main에 병합합니다.

9.2.1 브랜치 생성
  1. Current Branch 클릭
    상단의 Current Branch 드롭다운을 클릭합니다.
  2. New Branch 클릭
    New Branch 버튼 클릭 → 브랜치 이름 입력(예: feature/dark-mode) → Create Branch. 현재 브랜치에서 분기됩니다.
  3. 분기 기점 선택
    특정 브랜치에서 분기할 경우 "Create branch based on..." 드롭다운에서 선택합니다.
9.2.2 브랜치 전환

Current Branch 드롭다운에서 이동할 브랜치를 클릭합니다. 작업 중인 파일이 있으면 stash 여부를 묻는 다이얼로그가 나타납니다.

9.2.3 원격 브랜치 추적

팀원이 push한 브랜치를 로컬에 가져오려면 Current Branch → Other Branches 탭에서 원격 브랜치를 클릭합니다. 자동으로 로컬 추적 브랜치가 생성됩니다.

9.3 커밋과 PR

GitHub Desktop의 커밋 → PR 전체 협업 워크플로우입니다.

9.3.1 커밋
  1. Changes 탭에서 파일 선택
    체크박스로 커밋에 포함할 파일 선택. 파일 클릭 시 오른쪽에 diff 확인 가능.
  2. 커밋 메시지 작성
    Summary(제목, 필수)와 Description(본문, 선택) 입력. Conventional Commits 타입 (feat:, fix: 등)을 Summary에 포함하는 것을 권장합니다.
  3. Commit to <브랜치명> 클릭
    커밋 완료. History 탭에서 방금 만든 커밋을 확인할 수 있습니다.
9.3.2 Pull Request 생성
  1. Push origin
    커밋 후 Push origin으로 원격에 업로드합니다.
  2. Create Pull Request
    Push 후 Create Pull Request 버튼 클릭 → 브라우저에서 GitHub PR 작성 페이지가 열립니다.
  3. PR 내용 작성 및 제출
    제목, 설명, 리뷰어, 레이블 등을 작성하고 Create pull request 클릭.

9.4 자주 사용하는 명령어를 손쉽게 사용하기

CLI 명령어와 GitHub Desktop의 UI 동작을 대응해 정리합니다. CLI를 배웠으나 GUI도 함께 사용하고 싶을 때 참고하세요.

CLI 명령어 → GitHub Desktop 대응표
git statusChanges 탭 — 수정된 파일이 자동으로 표시됨
git add <file>파일 옆 체크박스 체크
git add .파일 목록 상단의 전체 체크박스 체크
git commit -m "msg"Summary 입력 → Commit to <branch> 클릭
git push상단 Push origin 버튼 클릭
git pull상단 Fetch origin → Pull origin 클릭
git fetch상단 Fetch origin 클릭 (Pull 없이 확인만)
git branch -c feature/xCurrent Branch → New Branch → 이름 입력 → Create
git switch feature/xCurrent Branch 드롭다운 → 브랜치 이름 클릭
git log --onelineHistory 탭 — 커밋 이력 시각적으로 표시
git diffChanges 탭에서 파일 클릭 시 오른쪽에 diff 표시
git stash브랜치 전환 시 미커밋 파일 있으면 stash 여부 다이얼로그
git mergeBranch → Merge into Current Branch 메뉴
git cloneFile → Clone Repository → URL 또는 GitHub 검색
git remote -vRepository → Repository Settings → Remote 탭
git commit --amendHistory 탭 → 마지막 커밋 우클릭 → Amend commit
git revert <hash>History 탭 → 커밋 우클릭 → Revert this commit
git cherry-pick <hash>History 탭 → 커밋 우클릭 → Cherry-pick commit
⚠️
GitHub Desktop이 지원하지 않는 작업
Interactive rebase (git rebase -i), reflog, 복잡한 stash 관리 등 고급 작업은 GitHub Desktop GUI로 수행할 수 없습니다. 이런 경우 우측 상단 Repository → Open in Terminal을 클릭해 CLI로 전환하세요.
부록 A — Git 명령어 노트
A

부록 A: Git 명령어 빠른 참조 노트

설정·기본·응용 명령어를 카테고리별로 정리한 치트시트입니다. 필요할 때마다 바로 펼쳐보는 레퍼런스로 활용하세요.

cheatsheetconfig기본 명령어고급 명령어
🔗 부록 — 참고 자료 & 레퍼런스

A.1 설정 명령어

Git 설정
git config --global user.name "이름"전역 사용자 이름 설정 (커밋에 기록됨)
git config --global user.email "이메일"전역 이메일 설정 (GitHub 계정과 일치 권장)
git config --global init.defaultBranch main기본 브랜치명을 main으로 설정
git config --global core.autocrlf true줄바꿈 자동 변환 (Windows: true, Mac/Linux: input)
git config --global core.editor code --wait기본 에디터를 VS Code로 설정
git config --list현재 설정 전체 출력
git config user.name특정 설정값만 확인
git config --global --edit~/.gitconfig 파일을 에디터로 직접 편집
git config --local user.email "회사@corp.com"특정 저장소에만 다른 이메일 설정

A.2 기본 명령어

저장소 초기화 · 복제
git init현재 폴더를 Git 저장소로 초기화
git init 폴더명새 폴더를 만들고 초기화
git clone <URL>원격 저장소 전체를 로컬에 복제
git clone <URL> 폴더명지정 폴더명으로 복제
git clone -b 브랜치명 <URL>특정 브랜치만 복제
상태 · 스테이징 · 커밋
git status작업 디렉터리와 스테이징 상태 표시
git status -s간략한 상태 표시 (M=수정, A=추가, ?=untracked)
git add <파일>파일을 스테이징 영역에 추가
git add .현재 디렉터리 모든 변경 파일 스테이징
git add -p파일 내 일부 변경만 선택해 스테이징 (interactive)
git commit -m "메시지"스테이징 영역을 커밋
git commit -am "메시지"tracked 파일 전체를 add + commit (한 번에)
git commit --amend마지막 커밋 수정 (메시지 또는 내용)
git commit --amend --no-edit메시지 유지하고 내용만 수정
이력 조회
git log전체 커밋 이력 (q 키로 종료)
git log --oneline한 줄로 간략히
git log --oneline --graph --all모든 브랜치를 그래프로 시각화
git log -N최근 N개 커밋만 출력
git log --follow 파일명파일 이름 변경 이력 포함해 조회
git log --author="이름"특정 작성자의 커밋만 필터
git diff작업 디렉터리와 스테이징 비교
git diff --staged스테이징과 마지막 커밋 비교
git diff 브랜치A..브랜치B두 브랜치 간 차이 비교
git show 해시특정 커밋의 상세 내용 출력
원격 저장소
git remote add origin <URL>원격 저장소 등록
git remote -v원격 저장소 목록 + URL 확인
git remote set-url origin <URL>원격 URL 변경
git remote remove origin원격 저장소 연결 해제
git push -u origin main처음 push 및 upstream 설정
git pushupstream 설정 후 간단히 push
git push origin --delete 브랜치명원격 브랜치 삭제
git fetch origin원격 변경 사항 가져오기 (병합 안 함)
git pullfetch + merge (원격 변경 반영)
git pull --rebasepull 시 merge 대신 rebase 사용
브랜치 기본
git branch로컬 브랜치 목록
git branch -v브랜치별 최근 커밋 표시
git branch -a로컬 + 원격 브랜치 모두 표시
git branch 브랜치명브랜치 생성 (전환 안 함)
git switch 브랜치명브랜치 전환
git switch -c 브랜치명브랜치 생성 + 즉시 전환 (가장 많이 사용)
git switch -이전 브랜치로 돌아가기
git branch -m 새이름현재 브랜치명 변경
git branch -d 브랜치명브랜치 삭제 (병합된 경우만)
git branch -D 브랜치명브랜치 강제 삭제
git merge 브랜치명현재 브랜치에 대상 브랜치 병합
git merge --no-ff 브랜치명Fast-forward 방지 — 항상 merge commit 생성
git merge --abort병합 중단 (충돌 해결 포기)
복원 · 되돌리기
git restore 파일명작업 디렉터리 변경 취소 (마지막 커밋으로 복원)
git restore .모든 변경 취소
git restore --staged 파일명스테이징 취소 (파일은 그대로)
git reset --soft HEAD~1마지막 커밋 취소, 변경 사항 staged 유지
git reset HEAD~1마지막 커밋 취소, 변경 사항 unstaged
git reset --hard HEAD~1마지막 커밋 + 변경 사항 모두 삭제 ⚠️
git revert 해시특정 커밋을 되돌리는 새 커밋 생성 (안전)
git revert --no-edit 해시에디터 없이 revert

A.3 응용 명령어

Stash — 임시 저장
git stash현재 변경 사항 임시 저장
git stash push -m "설명"설명과 함께 stash (권장)
git stash -uUntracked 파일도 함께 stash
git stash liststash 목록 확인
git stash pop최근 stash 적용 + 목록에서 제거
git stash apply stash@{N}특정 stash 적용 (목록은 유지)
git stash drop stash@{N}특정 stash 삭제
git stash clear모든 stash 삭제
Cherry-pick · Rebase · Reflog
git cherry-pick 해시특정 커밋만 현재 브랜치에 적용
git cherry-pick --no-commit 해시커밋 없이 작업 디렉터리에만 적용
git cherry-pick --abortcherry-pick 중단
git rebase 브랜치명현재 브랜치를 대상 브랜치 위로 재적용
git rebase -i HEAD~N최근 N개 커밋 인터랙티브 편집
git rebase --continue충돌 해결 후 rebase 계속
git rebase --abortrebase 중단 및 원 상태 복구
git reflogHEAD 이동 전체 이력 (90일 보존)
git reset --hard HEAD@{N}reflog 특정 시점으로 복구
.gitignore — 추적 제외 파일
.gitignore 파일 생성저장소 루트에 위치. 패턴별로 Git 추적에서 제외
node_modules/.gitignore 예시: node_modules 폴더 전체 제외
*.log.gitignore 예시: 모든 .log 파일 제외
.env.gitignore 예시: 환경변수 파일 제외 (비밀키 보호)
git rm --cached 파일명이미 추적 중인 파일을 .gitignore 적용 (로컬 파일은 유지)
gitignore.io언어·프레임워크별 .gitignore 자동 생성 사이트
태그(Tag) — 버전 관리
git tag v1.0.0현재 커밋에 경량 태그 생성
git tag -a v1.0.0 -m "설명"주석 태그 생성 (릴리즈에 사용)
git tag태그 목록
git push origin v1.0.0태그를 원격에 push (기본 push에는 포함 안 됨)
git push origin --tags모든 태그 push
git tag -d v1.0.0로컬 태그 삭제
🎯 Git 마스터를 위한 다음 단계
  • GitHub Actions: push 또는 PR 발생 시 자동으로 테스트·빌드·배포 파이프라인 실행
  • Git Hooks: 커밋 전(pre-commit), push 전(pre-push) 자동 코드 검사·포맷팅 실행
  • Monorepo 전략: 여러 서비스·패키지를 하나의 저장소에서 관리하는 방법
  • Git Submodules: 외부 저장소를 내 저장소에 포함시키는 방법
  • Signed Commits: GPG 키로 커밋 작성자를 암호학적으로 검증