— DevOps Lecture 2026 · Introduction to Git & GitHub

🐙 GitHub 핵심 총정리

Git의 기본 원리부터 GitHub를 이용한 실전 협업 워크플로우까지, DevOps 엔지니어의 필수 도구를 마스터합니다.

2026 DevOps

22 슬라이드

강의 + 실습

01 — Git이란 무엇인가?

📚 Git이란 무엇인가?

Git의 정의

Git은 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템(DVCS)입니다.

DVCS : Distributed Version Control System

🐧 2005년 리누스 토발즈(Linus Torvalds)가 리눅스 커널 개발을 위해 만들었으며, 현재 세계에서 가장 널리 사용되는 버전 관리 시스템입니다.

💡 왜 Git을 사용해야 할까요?

⏱️ 효율적인 협업: 누가, 언제, 무엇을 변경했는지 기록하고 충돌을 방지합니다.
🔙 과거로의 여행: 언제든지 이전 버전의 코드로 되돌릴 수 있습니다. (Time Machine)
🔀 안전한 실험: '브랜치'를 만들어 원본 코드에 영향 없이 새로운 기능을 개발할 수 있습니다.
🛡️ 데이터 백업: 원격 저장소(GitHub 등)에 코드를 안전하게 보관합니다.

Git vs GitHub

구분	Git	GitHub
정의	버전 관리 소프트웨어 (Tool)	Git 저장소 호스팅 서비스 (Cloud)
설치	로컬 컴퓨터에 설치 필요	웹 브라우저로 접속
용도	소스 코드 버전 관리	협업, 백업, 코드 리뷰, 이슈 트래킹

Git의 3가지 영역 (Workflow)

1. Working Directory (작업 공간) : 실제 파일을 수정하는 곳
        ↓ (git add)
2. Staging Area (임시 저장소) : 커밋할 파일들을 골라놓는 곳
        ↓ (git commit)
3. Repository (저장소) : 버전이 영구적으로 저장되는 곳

02 — Git 설치

⚙️ Git 설치

🐧 Linux (Red Hat 계열)

Red Hat 계열(RHEL, CentOS, Fedora)에서는 dnf 또는 yum 패키지 매니저를 사용합니다.

# 최신 버전 확인
sudo dnf install git -y

# 또는 (구버전 OS)
sudo yum install git -y

# 설치 확인
git --version

🪟 Windows

Windows에서는 공식 사이트에서 설치 파일을 다운로드하여 설치합니다.

공식 사이트 접속: https://git-scm.com/
Download for Windows 버튼 클릭
설치 파일 실행 후 기본 옵션으로 설치 진행
설치 완료 후 Git Bash 또는 명령 프롬프트에서 확인

# 설치 확인 (Git Bash 또는 CMD)
git --version

Git 공식 사이트 다운로드 페이지

03 — 초기 설정 & 저장소

🔧 초기 설정 및 저장소 초기화

Git 저장소 초기화

프로젝트 폴더를 Git으로 관리하려면 git init 명령어로 저장소를 초기화합니다. 이 명령어를 실행하면 해당 폴더에 .git 숨김 폴더가 생성되며, Git이 변경사항을 추적하기 시작합니다.

# 연습용 폴더 생성
mkdir sandbox
cd sandbox

# Git 저장소 초기화
git init

💡 .git 폴더란?

.git 폴더에는 저장소의 모든 메타데이터(커밋 이력, 브랜치 정보, 설정 등)가 저장됩니다. 이 폴더를 삭제하면 Git 추적이 완전히 제거됩니다.

초기 설정

Git을 설치한 후, 가장 먼저 해야 할 일은 사용자 정보를 설정하는 것입니다. 이 정보는 매 커밋에 기록되므로, 협업 시 누가 작업했는지 식별하는 데 사용됩니다.

git config --global user.name "사용자 이름"
git config --global user.email "이메일 주소"

# 설정 확인
git config --global --list

💡 --global 옵션은 시스템 전체에 적용됩니다. 특정 프로젝트에만 다른 설정을 적용하려면 해당 디렉토리에서 --global 없이 실행하세요.

04 — SSL 보안 설정

🔒 SSL 보안 설정

사내 네트워크나 사설 인증서를 사용하는 환경에서는 Git이 SSL 인증서를 검증하지 못해 push나 clone이 실패할 수 있습니다. 이런 경우 SSL 검증을 비활성화할 수 있습니다.

⚠️ SSL 검증 비활성화

보안 정책에 따라 자체 서명 인증서(Self-signed Certificate)를 사용하는 환경에서는 아래 설정이 필요할 수 있습니다.

# SSL 인증서 검증 비활성화 (전역 설정)
git config --global http.sslverify false

      💡 언제 사용하나요?
      사내 프록시 서버를 통해 GitHub에 접속할 때
사설 GitLab/GitHub Enterprise 서버를 사용할 때
자체 서명된 SSL 인증서를 사용하는 환경일 때

    

🔓 SSL 검증 다시 활성화 (해제)

보안상 SSL 검증을 비활성화한 상태를 계속 유지하는 것은 권장하지 않습니다. 작업이 끝나면 아래 명령어로 설정을 원래대로 되돌려야 합니다.

# SSL 검증 설정 해제 (기본값인 true로 복원)
git config --global --unset http.sslverify

💡 --unset은 설정 자체를 제거합니다. 제거 후에는 Git이 기본 동작(SSL 검증 활성화)으로 돌아갑니다.

📋 설정 확인

# 현재 http 관련 설정 확인
git config --global --list | grep http

# sslverify 값만 확인
git config --global http.sslverify

⚠️ 주의사항

SSL 검증을 비활성화하면 중간자 공격(MITM)에 취약해질 수 있습니다. 반드시 필요한 경우에만 사용하고, 가능하면 올바른 인증서를 설치하는 것이 가장 좋은 방법입니다.

05 — 기본 명령어

🎯 기본 명령어

Git 워크플로우

Git에서 파일을 수정하고 원격 저장소에 반영하는 기본 흐름입니다.

파일 수정 → git add → git commit → git push

git status - 상태 확인

현재 작업 디렉토리의 상태를 확인합니다. 어떤 파일이 수정되었는지, 스테이징되었는지, 추적되지 않는 파일이 있는지 한눈에 파악할 수 있습니다.

git status

git add - 스테이징

커밋할 파일들을 Staging Area에 올리는 명령어입니다. 커밋 전에 반드시 실행해야 하며, 원하는 파일만 선택적으로 스테이징할 수 있습니다.

# 특정 파일만 스테이징
git add [파일명]

# 현재 디렉토리의 모든 변경사항 스테이징 (삭제된 파일 제외될 수 있음)
git add .

# 작업 디렉토리의 모든 변경사항 스테이징 (신규, 수정, 삭제 포함)
git add -A

💡 Tip: git add .은 현재 위치 기준, git add -A는 저장소 전체 기준입니다.

git commit - 버전 저장

스테이징된 변경사항을 하나의 버전(커밋)으로 저장합니다. 커밋 메시지는 나중에 변경 이력을 확인할 때 중요하므로, 명확하게 작성하는 것이 좋습니다.

# 메시지와 함께 커밋
git commit -m "커밋 메시지"

git push - GitHub에 업로드

로컬 저장소의 커밋들을 원격 저장소(GitHub)에 업로드합니다. 처음 push할 때는 -u origin main을 붙여 기본 원격 브랜치를 설정하고, 이후에는 git push만으로 가능합니다.

# 처음 push (원격 기본 브랜치 설정)
git push -u origin main

# 이후 push
git push

06 — GitHub 연동

🔗 GitHub 연동하기

GitHub는 Git 저장소를 클라우드에 호스팅하는 서비스입니다. 로컬에서 작업한 내용을 GitHub에 업로드하거나, GitHub의 프로젝트를 로컬로 가져올 수 있습니다.

방법 1: 로컬 프로젝트를 GitHub에 연결

이미 로컬에서 작업 중인 프로젝트를 GitHub 저장소에 연결하는 방법입니다. GitHub에서 먼저 빈 저장소를 생성한 후 아래 명령어를 실행합니다.

# 1. Git 초기화 및 첫 커밋
git init
git add .
git commit -m "first commit"

# 2. 기본 브랜치명을 main으로 설정
git branch -M main

# 3. 원격 저장소 연결 및 push
git remote add origin https://github.com/username/repo.git
git push -u origin main

방법 2: GitHub 저장소 복제 (clone)

GitHub에 이미 있는 프로젝트를 로컬로 가져오는 방법입니다. git clone은 저장소의 모든 파일과 커밋 이력을 함께 다운로드합니다.

# 저장소 복제
git clone https://github.com/username/repo.git

# 복제된 폴더로 이동
cd repo

# 수정 후 커밋 및 푸시
git add .
git commit -m "수정 내용"
git push

pull과 fetch

다른 사람이 원격 저장소에 올린 변경사항을 내 로컬에 반영하는 명령어입니다.

# pull: 원격 변경사항을 가져와서 자동 병합 (fetch + merge)
git pull origin main

# fetch: 원격 변경사항을 가져오기만 함 (병합은 수동)
git fetch origin
git merge origin/main

💡 pull vs fetch: pull은 자동 병합되어 편리하지만, 충돌이 발생할 수 있습니다. fetch는 먼저 확인 후 병합할 수 있어 더 안전합니다.

07 — Token 설정

🔑 GitHub Token 설정

GitHub에 push할 때 비밀번호 대신 Personal Access Token (PAT)을 사용해야 합니다. 2021년부터 비밀번호 인증이 중단되었습니다.

📥 Token 생성 순서

      GitHub 로그인 → 오른쪽 상단 프로필 클릭 → Settings
왼쪽 메뉴 제일 아래 Developer settings 클릭
Personal access tokens → Tokens (classic) 선택
Generate new token → Generate new token (classic) 클릭

    

⚙️ Token 옵션 설정

항목	설정 값	설명
Note	용도 메모 (예: my-laptop)	Token의 용도를 구분하기 위한 이름
Expiration	90 days 또는 No expiration	Token 만료일 설정
repo	✅ 체크	저장소 접근 권한 (필수)
workflow	✅ 체크	GitHub Actions 사용 시 필요
admin:org	선택 사항	조직 관리 권한
delete_repo	선택 사항	저장소 삭제 권한

📝 Token 사용 방법

Token을 생성하면 한 번만 표시되므로 반드시 복사해서 안전한 곳에 보관하세요.

# push 시 비밀번호 대신 Token 입력
Username: your-github-username
Password: ghp_xxxxxxxxxxxxxxxxxxxx  (여기에 Token 붙여넣기)

💡 Tip: 매번 Token을 입력하기 귀찮다면, 아래 명령어로 자격 증명을 저장할 수 있습니다.

# 자격 증명 저장 (한 번만 입력하면 기억)
git config --global credential.helper store

⚠️ 주의사항

Token을 코드나 파일에 직접 작성하지 마세요.
Token이 노출되면 즉시 삭제하고 새로 생성하세요.
필요한 최소한의 권한만 부여하세요.

08 — 브랜치 관리

🌿 브랜치 관리

브랜치란?

브랜치(Branch)는 독립적인 작업 공간입니다. 마치 나무의 가지처럼, 원본 코드(main)에서 뿔어져 나와 독립적으로 작업한 뒤, 다시 원본에 합칠 수 있습니다.

왜 브랜치를 사용할까? — 여러 명이 동시에 다른 기능을 개발할 때, 서로의 코드에 영향을 주지 않고 독립적으로 작업할 수 있습니다.
main 브랜치 — 항상 안정적인 상태를 유지하는 기본 브랜치입니다.
feature 브랜치 — 새로운 기능 개발을 위해 만드는 임시 브랜치입니다.

브랜치 기본 명령어

# 브랜치 목록 확인
git branch

# 원격 브랜치 포함 목록
git branch -a

# 브랜치 생성 및 이동
git switch -c feature-login

# 브랜치 전환
git switch main

# 브랜치 삭제 (병합 완료된 브랜치)
git branch -d feature-login

# 브랜치 강제 삭제 (병합되지 않은 브랜치)
git branch -D feature-login

checkout vs switch

💡 Git 2.23부터 checkout 명령어의 역할이 switch와 restore로 분리되었습니다.

기능	checkout (기존)	switch/restore (새로운)
브랜치 전환	`git checkout main`	`git switch main`
브랜치 생성+전환	`git checkout -b feature`	`git switch -c feature`
파일 복원	`git checkout -- file.txt`	`git restore file.txt`

⚠️ checkout은 브랜치 전환과 파일 복원을 모두 처리하여 혼란이 있었습니다. 새로운 switch / restore 사용을 권장합니다.

브랜치 작업 흐름

# 1. main 브랜치에서 시작
git switch main

# 2. 새 기능 브랜치 생성
git switch -c feature-payment

# 3. 작업 후 커밋
git add .
git commit -m "feat: 결제 기능 추가"

# 4. 원격 저장소에 푸시
git push -u origin feature-payment

# 5. main에 병합
git switch main
git merge feature-payment

09 — Commit에서 브랜치 생성

📌 Commit에서 브랜치 생성

가끔 과거의 특정 시점(커밋)으로 돌아가서 새로운 작업을 시작해야 할 때가 있습니다. 이때 특정 커밋 해시를 이용하여 브랜치를 만들 수 있습니다.

1. 커밋 해시 확인

이동하고 싶은 지점의 커밋 해시(Hash)를 git log 명령어로 확인합니다.

git log --oneline
a1b2c3d (HEAD -> main) feat: 최종 기능 완료
e4f5g6h feat: 중간 점검 커밋
i7j8k9l init: 초기 세팅 완료

2. 특정 커밋에서 브랜치 생성

확인한 해시값을 사용하여 새 브랜치를 만듭니다.

# git switch -c [새 브랜치명] [커밋 해시]
git switch -c fix-old-bug e4f5g6h

10 — Merge

🔀 병합하기

Merge - 병합

Merge는 두 브랜치의 개발 이력을 모두 보존하면서 하나로 합칩니다. 병합 커밋(Merge Commit)이 생성되며, 누가 언제 병합했는지 기록이 남습니다.

# feature 브랜치를 main에 병합
git switch main
git merge feature-login

# 병합 후 원격 저장소에 반영
git push origin main

      💡 Fast-Forward Merge vs 3-Way Merge
      Fast-Forward: main에 새로운 커밋이 없으면, feature 브랜치의 커밋들이 그대로 main에 이어집니다. (병합 커밋 없음)
3-Way Merge: main에도 새로운 커밋이 있으면, 두 브랜치의 변경사항을 합치는 병합 커밋이 생성됩니다.

    

11 — 실전 워크플로우

💼 실전 워크플로우

1. 협업 시나리오 (GitHub Flow)

Scenario: 팀원들과 함께 '로그인 기능'을 개발하는 상황입니다.

STEP 1: 이슈 확인 및 브랜치 생성

# 1. 원격 저장소의 최신 변경사항을 가져옵니다.
git switch main
git pull origin main

# 2. 새로운 기능 개발을 위한 브랜치를 생성합니다.
git switch -c feature/login

STEP 2: 개발 및 커밋

# 열심히 코딩 후...
git add .
git commit -m "feat: 로그인 UI 구현"
git commit -m "feat: 로그인 API 연동"

STEP 3: Push 및 Pull Request (PR)

# 내 브랜치를 원격 저장소에 올립니다.
git push -u origin feature/login

# GitHub 웹사이트에서 'Compare & Pull Request' 버튼 클릭!
# 팀원들에게 코드 리뷰를 요청합니다.

STEP 4: 코드 리뷰 및 Merge

팀원들이 코드를 리뷰하고 승인(Approve)합니다.
충돌이 없다면 Merge Pull Request 버튼을 눌러 main에 합칩니다.
작업이 끝난 브랜치는 삭제합니다.

2. 커밋 메시지 규칙 (Convention)

💡 좋은 커밋 메시지는 프로젝트의 유지보수성을 높여줍니다.

feat:     새로운 기능 추가
fix:      버그 수정
docs:     문서 수정
style:    코드 포맷팅 (로직 변경 없음)
refactor: 코드 리팩토링

3. .gitignore 설정 (필수!)

보안 정보나 불필요한 파일은 절대 올리면 안 됩니다.

# 의존성 모듈
node_modules/
dist/

# 환경 변수 (API Key 등)
.env
.env.local

# OS 시스템 파일
.DS_Store
Thumbs.db

12 — Pull Request

🚀 Pull Request (PR)

Pull Request는 내가 작업한 브랜치를 main 브랜치에 병합해달라고 팀원들에게 요청하는 GitHub의 핵심 기능입니다.

PR이 필요한 이유

코드 리뷰: 팀원이 코드를 검토하여 버그를 사전에 발견할 수 있습니다.
협업 기록: 어떤 변경이 왜 이루어졌는지 기록이 남습니다.
품질 보장: 승인 없이는 main에 직접 병합할 수 없도록 보호합니다.

PR 생성 순서

      feature 브랜치에서 작업 완료 후 git push
GitHub 웹사이트에서 "Compare & Pull Request" 버튼 클릭
PR 제목과 설명 작성 (어떤 변경을 했는지)
Reviewer(검토자) 지정
"Create Pull Request" 버튼 클릭

    

PR 리뷰 및 Merge

단계	담당	설명
1. 코드 리뷰	Reviewer	변경된 코드를 확인하고 코멘트 작성
2. 수정 요청	Reviewer	필요시 수정 사항을 요청 (Request Changes)
3. 수정 반영	작성자	수정 후 추가 커밋 & push (PR에 자동 반영)
4. 승인	Reviewer	Approve 버튼 클릭
5. Merge	작성자/관리자	Merge Pull Request 버튼으로 병합

Merge 전략

Merge commit: 병합 커밋을 생성하여 전체 이력 보존 (기본값)
Squash and merge: 여러 커밋을 하나로 합쳐서 병합 (깔끔한 이력)
Rebase and merge: 커밋을 재배치하여 선형 이력 유지

13 — 협업 실습

💻 협업 실습: Pull Request

팀원과 함께 GitHub에서 브랜치를 만들고 Pull Request를 통해 코드를 병합하는 과정을 실습합니다.

👨‍💻 팀장 (저장소 생성 및 멤버 초대)

      GitHub에서 Public Repository 생성 (Add a README file 체크 ✅)
저장소 화면 오른쪽 위 Settings 클릭
왼쪽 메뉴에서 Collaborators 클릭 후 Add people 버튼 클릭
팀원의 GitHub 계정명(또는 이메일)을 검색하여 초대 (초대된 팀원은 이메일 및 알림 확인 후 수락)

    

👩‍💻 팀원 (작업 및 PR 생성)

      초대를 수락한 팀원은 팀장의 저장소로 이동하여 로컬로 Clone (또는 GitHub 웹에서 직접 작업)
새 브랜치 생성: git switch -c feature/add-intro
README.md 파일 하단에 본인의 소개(이름, 역할 등)를 추가
수정된 파일을 커밋하고 원격 저장소에 Push: git push -u origin feature/add-intro
저장소 웹페이지에서 Compare & pull request 버튼 클릭하여 PR 생성

    

🤝 함께 (코드 리뷰 및 Merge)

코드 리뷰: 팀장은 PR의 Files changed 탭에서 팀원의 변경사항을 확인하고 피드백 코멘트를 남깁니다.
Merge: Merge pull request 클릭 → Confirm merge
병합이 완료되면 팀장은 로컬에서 main 브랜치로 이동 후 git pull origin main하여 최신 상태 동기화!

14 — GitHub Desktop

🖥️ GitHub Desktop

GitHub Desktop은 Git과 GitHub를 GUI(그래픽 인터페이스)로 사용할 수 있게 해주는 공식 데스크톱 애플리케이션입니다. 명령어 없이도 Git 작업을 수행할 수 있어 입문자에게 특히 유용합니다.

💡 왜 GitHub Desktop을 사용할까?

직관적인 UI: 커밋, 브랜치, 푸시 등의 작업을 클릭만으로 처리할 수 있습니다.
시각적 diff: 파일 변경사항을 색상으로 구분하여 한눈에 확인 가능합니다.
충돌 해결: Merge 충돌 시 시각적으로 어떤 부분이 충돌했는지 보여줍니다.
GitHub 연동: 로그인만 하면 저장소 목록, PR 생성 등을 바로 사용할 수 있습니다.

📥 설치 방법

공식 사이트 접속: https://desktop.github.com/download/
Download for Windows (64bit) 버튼 클릭
설치 파일 실행 후 GitHub 계정으로 로그인
기존 저장소를 Clone하거나 새 저장소를 생성하여 시작

GitHub Desktop 설치 페이지

🔄 주요 기능

기능	CLI 명령어	GitHub Desktop
저장소 복제	`git clone [URL]`	File → Clone Repository
변경사항 확인	`git status / git diff`	Changes 탭에서 시각적 확인
커밋	`git add . && git commit`	Summary 작성 후 Commit 버튼
Push	`git push`	Push origin 버튼
브랜치 전환	`git switch [branch]`	상단 Branch 드롭다운
PR 생성	GitHub 웹에서 생성	Branch → Create Pull Request

💡 Tip: GitHub Desktop은 CLI를 완전히 대체하는 것이 아니라, 보조 도구로 활용하는 것을 추천합니다. 기본적인 CLI 명령어를 익힌 후 GitHub Desktop을 함께 사용하면 생산성이 크게 향상됩니다.

15 — Desktop 브랜치

🌿 Desktop: 브랜치 생성하기

GitHub Desktop에서는 명령어 없이 클릭 몇 번으로 새로운 브랜치를 생성할 수 있습니다.

🛠️ 브랜치 생성 순서

      상단 메뉴에서 Current Branch 버튼을 클릭합니다.
드롭다운에서 New Branch 버튼을 클릭합니다.
브랜치 이름을 입력합니다. (예: feature/login)
Create Branch 버튼을 클릭하면 새 브랜치가 생성되고 자동으로 전환됩니다.

    

⌨️ CLI 대응 명령어

# CLI에서의 동일한 작업
git switch -c feature/login

GitHub Desktop에서 브랜치 생성하기

💡 Tip: 브랜치 이름은 feature/기능명, fix/버그명 형식으로 작성하면 목적을 명확하게 구분할 수 있습니다.

16 — Desktop 브랜치 생성 (from Commit)

🌿 Desktop: 특정 Commit에서 브랜치 생성

GitHub Desktop의 History 기능을 사용하면 과거의 특정 시점(커밋)에서 바로 브랜치를 만들 수 있습니다.

🛠️ 브랜치 생성 순서

      왼쪽 상단의 History 탭을 클릭합니다.
커밋 목록에서 브랜치를 만들고 싶은 특정 커밋을 찾아 마우스 우클릭을 합니다.
메뉴에서 Create Branch from Commit...을 클릭합니다.
새로운 브랜치 이름을 입력하고 Create Branch 버튼을 누릅니다.

    

⌨️ CLI 대응 명령어

# CLI에서의 동일한 작업
git switch -c fix-old-bug e4f5g6h

GitHub Desktop에서 특정 커밋으로 브랜치 생성하기

💡 Tip: 이 기능은 과거 상태의 코드를 기반으로 긴급 수정을 하거나 실험적인 작업을 시작할 때 매우 유용합니다.

17 — Desktop 브랜치 전환

🔀 Desktop: 브랜치 전환하기

여러 브랜치 사이를 오가며 작업할 때, GitHub Desktop에서는 클릭 한 번으로 브랜치를 전환할 수 있습니다.

🛠️ 브랜치 전환 순서

      상단 메뉴에서 Current Branch 버튼을 클릭합니다.
브랜치 목록에서 전환하고 싶은 브랜치를 클릭합니다.
클릭하는 순간 해당 브랜치로 자동 전환됩니다.

    

⌨️ CLI 대응 명령어

# CLI에서의 동일한 작업
git switch main
git switch feature/login

GitHub Desktop에서 브랜치 전환하기

⚠️ 주의: 브랜치를 전환하기 전에 현재 작업 중인 변경사항을 커밋하거나 Stash해야 합니다. 그렇지 않으면 변경사항이 다른 브랜치로 함께 이동될 수 있습니다.

18 — Desktop 브랜치 병합

🔀 Desktop: 브랜치 Merge하기

기능 개발이 완료되면, 해당 브랜치를 main 브랜치에 병합(Merge)하여 변경사항을 반영합니다.

🛠️ Merge 순서

      먼저 병합 대상인 main 브랜치로 전환합니다. (Current Branch → main)
상단 메뉴에서 Branch → Merge into Current Branch를 클릭합니다.
병합할 브랜치(예: feature/login)를 선택합니다.
Merge feature/login into main 버튼을 클릭합니다.
병합 완료 후 Push origin을 눌러 원격 저장소에 반영합니다.

    

⌨️ CLI 대응 명령어

# CLI에서의 동일한 작업
git switch main
git merge feature/login
git push origin main

GitHub Desktop에서 브랜치 Merge하기

💡 Tip: 충돌(Conflict)이 발생하면 GitHub Desktop이 충돌 파일을 알려줍니다. 해당 파일을 열어 충돌 부분을 수정한 후, 커밋하면 병합이 완료됩니다.

19 — Desktop PR 생성

🚀 Desktop: Pull Request 생성하기

브랜치에서 작업이 완료되면, Pull Request(PR)를 생성하여 팀원들에게 코드 리뷰를 요청할 수 있습니다. GitHub Desktop에서 간편하게 PR을 생성할 수 있습니다.

🛠️ Pull Request 생성 순서

      작업 브랜치(예: dev)에서 모든 변경사항을 커밋하고 Push합니다.
GitHub Desktop 메인 화면에서 "Preview Pull Request" 버튼을 클릭합니다.

            (또는 Branch 메뉴 → Create Pull Request / 단축키 Ctrl + Alt + P)
변경사항(추가/삭제된 코드)을 미리 확인합니다.
"Create Pull Request"를 클릭하면 GitHub 웹 페이지가 자동으로 열립니다.

    

GitHub Desktop에서 Pull Request 미리보기 및 생성

💡 Tip: PR 미리보기 화면에서 base 브랜치(병합 대상)와 compare 브랜치(작업 브랜치)가 올바르게 설정되어 있는지 확인하세요.

20 — 웹 PR 관리

🌐 웹: PR 리뷰 및 Merge

GitHub Desktop에서 PR을 생성하면 GitHub 웹 페이지로 이동합니다. 여기서 PR 제목과 설명을 작성하고, 팀원의 코드 리뷰를 거쳐 최종 Merge를 진행합니다.

📝 PR 작성 및 리뷰

      PR 제목과 설명을 작성하고 "Create Pull Request" 버튼을 클릭합니다.
팀원이 Conversation, Commits, Files changed 탭에서 코드를 리뷰합니다.
필요시 코멘트를 남기고 수정을 요청합니다.

    

✅ Merge 진행

      충돌이 없으면 "No conflicts with base branch" 메시지가 표시됩니다.
"Merge pull request" 버튼을 클릭하여 병합을 완료합니다.
병합 후 "Pull request successfully merged and closed" 메시지가 나타납니다.
작업이 완료된 브랜치는 "Delete branch" 버튼으로 삭제할 수 있습니다.

    

GitHub 웹에서 PR Merge 진행 (Open → Merged)

💡 Tip: 직접 Merge하는 것보다 PR 기반의 협업이 코드 품질을 높이는 데 효과적입니다. 코멘트를 통해 피드백을 주고받으며 더 나은 코드를 만들어갈 수 있습니다.

21 — Desktop 이력 확인

📜 Desktop: 커밋 히스토리 확인

이전에 진행한 커밋들의 내용을 GitHub Desktop에서 시각적으로 확인할 수 있습니다.

🛠️ 커밋 히스토리 확인 방법

      왼쪽 탭에서 History 탭을 클릭합니다.
커밋 목록이 시간순으로 표시됩니다. (최신 커밋이 상단)
특정 커밋을 클릭하면 오른쪽에 변경된 파일 목록과 변경 내용(diff)이 표시됩니다.
추가된 줄은 녹색, 삭제된 줄은 빨간색으로 구분됩니다.

    

⌨️ CLI 대응 명령어

# 커밋 이력 확인
git log --oneline

# 특정 커밋의 변경 내용 확인
git show [커밋해시]

# 변경사항 비교
git diff

GitHub Desktop에서 커밋 히스토리 확인하기

💡 Tip: History 탭에서 커밋을 우클릭하면 Revert this commit (이 커밋 되돌리기) 옵션을 사용할 수 있습니다. 실수로 커밋한 내용을 안전하게 되돌릴 때 유용합니다.

22 — 핵심 요약

📌 핵심 정리

1️⃣ Git의 3가지 영역

Working Directory  →(git add)→  Staging Area  →(git commit)→  Repository
   실제 파일 수정                커밋할 파일 선택              버전 영구 저장

2️⃣ 필수 명령어

명령어	설명
`git init`	Git 저장소 초기화 (.git 폴더 생성)
`git config --global user.name/email`	사용자 이름/이메일 설정
`git status`	현재 작업 디렉토리 상태 확인
`git add . / git add -A`	변경 파일을 Staging Area에 추가
`git commit -m "메시지"`	스테이징된 변경사항을 버전으로 저장
`git log --oneline`	커밋 이력 확인
`git push -u origin main`	원격 저장소에 업로드 (최초 1회)
`git pull origin main`	원격 변경사항을 로컬로 가져와 병합

3️⃣ GitHub 연동 & Token

# 로컬 → GitHub 연결
git remote add origin https://github.com/username/repo.git
git push -u origin main

# GitHub → 로컬 복제
git clone https://github.com/username/repo.git

💡 PAT (Personal Access Token): 2021년부터 비밀번호 대신 Token 사용 필수. GitHub Settings → Developer settings → Personal access tokens에서 발급. repo 권한 체크 후 생성하며, 한 번만 표시되므로 즉시 복사 보관.

4️⃣ 브랜치 관리

명령어	설명
`git branch`	브랜치 목록 확인
`git switch -c feature/기능명`	새 브랜치 생성 & 전환
`git switch -c 명칭 [Hash]`	특정 커밋(Hash)에서 브랜치 생성
`git switch main`	브랜치 전환
`git merge feature/기능명`	브랜치 병합 (main에서 실행)
`git branch -d feature/기능명`	병합 완료된 브랜치 삭제

⚠️ Merge 병합: Merge는 병합 커밋이 생기며 이력이 보존됩니다. 협업과 공유 브랜치 관리에 권장되는 안전한 방식입니다.

5️⃣ Pull Request (PR) 프로세스

      feature 브랜치에서 작업 완료 후 git push -u origin feature/기능명
GitHub 웹 → "Compare & Pull Request" 클릭
PR 제목/설명 작성 → Reviewer 지정 → "Create Pull Request"
팀원 코드 리뷰 → Approve → "Merge Pull Request"
병합 완료 후 "Delete branch"로 feature 브랜치 삭제

    

6️⃣ GitHub Desktop 주요 기능

작업	CLI	GitHub Desktop
브랜치 생성	`git switch -c feature`	Current Branch → New Branch
브랜치 전환	`git switch main`	Current Branch 드롭다운 클릭
브랜치 병합	`git merge feature`	Branch → Merge into Current Branch
PR 생성	GitHub 웹에서 생성	Branch → Create Pull Request
커밋 히스토리	`git log --oneline`	History 탭에서 시각적 확인

7️⃣ 실전 팁

커밋 메시지 규칙: feat: 기능 추가 / fix: 버그 수정 / docs: 문서 / refactor: 리팩토링
.gitignore: node_modules/, .env, .DS_Store 등 민감하거나 불필요한 파일은 반드시 제외
pull before push: push 전에 항상 git pull로 최신 상태 유지
GitHub Flow: main → feature 브랜치 생성 → 개발 → PR → 리뷰 → Merge → 삭제

🎉 축하합니다!

Git & GitHub의 핵심 개념부터 브랜치 전략, Pull Request, GitHub Desktop까지 완주하셨습니다! 이제 실전 협업 워크플로우를 자신있게 활용해보세요.