main 하나로 배우는 개인 작업 과정

집과 학원에서 이어서 하는 개인 GitHub

집에서 하던 프로젝트를 학원에서 열고, 학원에서 수정한 내용을 다시 집에서 이어서 작업합니다. 브랜치는 나누지 않고 main 하나만 사용하며, 작업 전 pull과 작업 후 push를 습관으로 만듭니다.

대상: Git·GitHub 입문자환경: Windows·VS Code작업 방식: 개인 저장소·main

먼저 이해하기

세 장소를 연결하는 규칙부터 기억하세요

집 컴퓨터, 학원 컴퓨터, GitHub 저장소는 서로 다른 장소입니다. 한 컴퓨터에서 파일만 저장하면 다른 컴퓨터에는 전달되지 않습니다. 현재 컴퓨터의 기록을 GitHub에 올리고, 다음 컴퓨터에서 그 기록을 가져와야 합니다.

Git과 GitHub는 역할이 다릅니다

Git내 컴퓨터

Git은 내 컴퓨터에서 파일 변경 이력을 기록합니다.

무엇을 언제 바꿨는지 기록하는 도구

GitHub인터넷

GitHub는 Git 기록을 인터넷에 보관합니다.

기록을 올리고 다른 컴퓨터에서 가져오는 서비스

먼저 Git으로 작업을 기록하고, 그 기록을 GitHub에 push합니다. 다른 컴퓨터에서는 GitHub의 기록을 pull하거나 clone합니다.

1집 또는 학원

파일을 수정하고 commit합니다.

2GitHub

push로 커밋을 올립니다.

3다음 컴퓨터

pull로 최신 커밋을 가져옵니다.

가장 중요한 주의사항

이전 컴퓨터에서 push하지 않은 작업은 다른 컴퓨터에서 pull할 수 없습니다.

commit

현재 컴퓨터의 작업 내용을 하나의 기록으로 저장합니다.

작업 단위가 끝났을 때

push

현재 컴퓨터의 커밋을 GitHub에 올립니다.

집이나 학원에서 작업을 마칠 때

pull

GitHub에 올라온 최신 커밋을 현재 컴퓨터로 가져옵니다.

집이나 학원에서 작업을 시작할 때

clone

저장소 전체를 프로젝트 폴더가 없는 컴퓨터에 처음 복제합니다.

새 학원 자리나 새 컴퓨터에서 처음 시작할 때

1단계

컴퓨터에서 처음 한 번 Git을 준비합니다

Git 공식 웹사이트에서 운영체제에 맞는 설치 파일을 받은 뒤 터미널에서 버전을 확인합니다. 버전 번호가 나오면 설치가 끝난 상태입니다.

Windows 시작 메뉴에서 Git Bash를 선택하는 화면 — Git 설치가 끝나면 시작 메뉴에서 Git Bash를 열 수 있습니다.

Git Bash에서 git --version 결과를 확인한 화면 — 버전 번호가 나오면 Git 설치가 완료된 상태입니다.

Git 설치 확인

git --version

집 개인 PC의 작성자 정보 설정

내가 계속 사용하는 컴퓨터라면 전역 설정인 --global을 사용합니다.

집 PC 사용자 정보

git config --global user.name "이름"
git config --global user.email "GitHub 이메일"
git config --global --list

VS Code에서 터미널 프로필을 선택하는 화면 — VS Code의 터미널 메뉴에서 사용할 명령어 창을 열 수 있습니다.

VS Code 확장 검색에서 Git Graph를 찾은 화면 — Git Graph 같은 확장은 기록을 눈으로 볼 때 유용하지만 Git 사용에 필수는 아닙니다.

VS Code 터미널만으로 모든 실습을 할 수 있습니다. Git Graph 같은 확장은 기록을 눈으로 확인할 때만 선택해서 설치합니다.

2단계

작성자 정보와 로그인 계정은 다릅니다

학원 공용 PC에는 이전 사용자의 정보가 남아 있을 수 있습니다. 커밋에 적히는 작성자와 GitHub에 접속하는 계정을 따로 확인해야 다른 사람 이름으로 커밋하거나 다른 계정으로 push하는 실수를 줄일 수 있습니다.

Git 작성자 정보

저장 위치: git config의 user.name과 user.email
하는 일: 커밋에 누구의 작업인지 기록합니다.
학원에서: 현재 저장소 안에서 내 이름과 이메일을 설정합니다.

Windows 자격 증명 관리자

저장 위치: Windows 제어판의 자격 증명 관리자
하는 일: GitHub에 로그인해 저장소를 pull·push할 계정을 기억합니다.
학원에서: 이전 학생의 GitHub 항목만 정리하고 내 계정으로 로그인합니다.

학원 공용 PC에서는 현재 프로젝트에만 작성자 설정

학원 PC 사용자 정보

git config user.name "이름"
git config user.email "GitHub 이메일"
git config --list

Windows 자격 증명 관리자에서 git:https://github.com 항목을 선택한 화면 — GitHub 항목을 펼쳐 계정을 확인하고, 이전 사용자의 항목일 때만 제거합니다.

Windows 자격 증명 관리자를 엽니다.
git:https://github.com처럼 GitHub와 관련된 항목만 확인합니다.
이전 학생의 계정이면 해당 GitHub 항목만 제거합니다.
브라우저의 GitHub 로그인 계정도 내 계정인지 확인합니다.
수업 종료 후 학원 정책에 따라 GitHub 자격 증명과 브라우저 로그인을 정리합니다.

다른 사람의 자료는 건드리지 않습니다

다른 학생의 프로젝트 폴더와 GitHub 이외의 Windows 자격 증명은 삭제하지 마세요.

3단계

GitHub에 빈 개인 저장소를 만듭니다

GitHub 왼쪽 영역의 New 저장소 버튼 — GitHub에서 New 버튼을 눌러 개인 저장소 만들기를 시작합니다.

GitHub 새 저장소 이름과 공개 범위를 입력하는 화면 — 저장소 이름과 공개 범위를 정한 뒤 Create repository를 누릅니다.

Repository name에 영문 소문자 중심의 프로젝트 이름을 입력합니다.
공개해도 되는 학습 프로젝트는 Public, 공개하면 안 되는 프로젝트는 Private을 선택합니다.
이미 내 컴퓨터에 프로젝트가 있다면 README, .gitignore, License는 체크하지 않습니다.
Create repository를 누르고 표시된 HTTPS 저장소 주소를 확인합니다.

4단계

기존 프로젝트를 GitHub에 처음 올립니다

VS Code에서 올릴 프로젝트 폴더를 연 뒤 아래 명령어를 한 줄씩 실행합니다. 전체를 한꺼번에 붙여넣지 않습니다.

GitHub가 새 저장소 연결 명령을 안내하는 화면 — GitHub의 안내를 참고하되 기존 프로젝트 전체는 git add .으로 추가합니다.

처음 업로드

git init
git status
git add .
git commit -m "first commit"
git branch -M main
git remote add origin 저장소주소
git push -u origin main

올리기 전에 확인하세요

.env, 비밀번호, API 키, node_modules는 저장소에 올리지 말고 .gitignore에서 제외합니다.

첫 push에서 GitHub 로그인

GitHub 연결 창에서 브라우저 로그인 버튼을 선택하는 화면 — 첫 push에서 로그인 창이 열리면 브라우저로 내 GitHub 계정에 로그인합니다.

Git Credential Manager의 GitHub 접근 권한을 승인하는 화면 — 계정과 권한을 확인한 뒤 Git Credential Manager 접근을 승인합니다.

브라우저 로그인 화면에서 내 계정을 확인하고 Git Credential Manager의 저장소 접근을 승인합니다.

5단계

올리지 않을 파일을 .gitignore로 제외합니다

비밀번호나 설치하면 다시 만들어지는 파일은 저장소에 올리지 않습니다. 프로젝트 루트에 .gitignore 파일을 만들고 제외할 대상을 적으면, Git이 그 파일들을 올리지 않습니다.

.gitignore 예시.gitignore

# 시스템 파일
.DS_Store
Thumbs.db

# 편집기 설정
.vscode/
.idea/

# 의존성과 빌드 산출물
node_modules/
dist/
build/

# 환경 변수와 비밀 값
.env
.env.*

# 로그
*.log

왜 제외하나
대상	이유
node_modules/	설치하면 다시 만들어지는 의존성 폴더라 올리지 않습니다.
.env	비밀번호·API 키 같은 민감한 값이라 올리면 안 됩니다.
.DS_Store	운영체제가 만든 파일이라 프로젝트와 관계없습니다.
dist/, build/	코드에서 다시 만들 수 있는 결과물이라 올리지 않습니다.

이미 올린 파일은 다릅니다

.gitignore는 아직 올리지 않은 파일에만 적용됩니다. 이미 올라간 파일은 따로 추적 해제해야 하므로, 처음 올리기 전에 .gitignore를 먼저 만드는 것이 안전합니다.

6단계

집과 학원에서 매번 같은 순서로 작업합니다

작업 장소가 바뀌어도 시작과 종료 순서는 같습니다. 이 순서를 지키면 main 하나로 작업해도 충돌 가능성을 크게 줄일 수 있습니다.

시작

작업 시작 전에는 pull

수정하기 전에 현재 폴더와 연결 주소를 확인하고 GitHub의 최신 커밋을 가져옵니다.

작업 시작

git status
git remote -v
git pull origin main

종료

작업 종료 전에는 push

현재 작업을 커밋해 GitHub에 올리고, 저장소 페이지에서 최근 커밋을 확인합니다.

작업 종료

git status
git add .
git commit -m "작업 내용"
git push origin main

자리에서 일어나기 전 확인

수정한 파일을 모두 저장했습니다.
git status로 남은 변경 내용을 확인했습니다.
commit과 push를 완료했습니다.
GitHub 웹사이트에서 최근 커밋을 확인했습니다.

7단계

학원에서 자리가 바뀌었다면

새 자리의 컴퓨터에 내 프로젝트 폴더가 있는지부터 확인합니다. 폴더가 없는 첫 작업과 이미 복제된 프로젝트의 최신화는 명령어가 다릅니다.

VS Code의 리포지토리 복제 입력창에 GitHub 주소를 붙여넣은 화면 — 새 학원 자리에서는 저장소 주소를 붙여넣어 내 프로젝트를 처음 복제합니다.

처음 사용하는 자리

프로젝트 폴더가 없음

clone으로 GitHub 저장소 전체를 새 폴더에 복제합니다.

새 자리에서 복제

git clone 저장소주소
cd 저장소이름
code .

전에 사용한 자리

프로젝트 폴더가 있음

내 저장소가 맞는지 확인한 뒤 pull로 최신 커밋을 가져옵니다.

기존 폴더 최신화

git status
git remote -v
git pull origin main

clone한 폴더에서는 다시 연결하지 않습니다

git init과 git remote add origin을 다시 실행하지 마세요. 다른 학생의 폴더도 덮어쓰거나 삭제하지 않습니다.

8단계

오류 문구를 지우기 전에 원인을 확인합니다

오류가 나면 강제 push하거나 프로젝트를 다시 만들지 말고, 터미널의 첫 오류 문구와 git status부터 확인합니다.

not a git repository

원인Git 저장소가 아닌 폴더에서 명령을 실행했습니다.

확인 순서VS Code에서 프로젝트 폴더를 다시 열고 git status를 실행합니다.

Author identity unknown

원인커밋 작성자 이름과 이메일이 설정되지 않았습니다.

확인 순서집 PC는 전역 설정, 학원 공용 PC는 현재 저장소 설정을 확인합니다.

remote origin already exists

원인origin이라는 원격 저장소가 이미 연결되어 있습니다.

확인 순서새로 추가하지 말고 git remote -v로 연결 주소를 확인합니다.

nothing to commit

원인저장할 변경 내용이 없거나 이미 커밋했습니다.

확인 순서파일 저장 여부와 git status 결과를 확인합니다.

push rejected

원인GitHub 저장소에 현재 컴퓨터에 없는 새 커밋이 있습니다.

확인 순서강제 push하지 말고 오류 문구를 확인한 뒤 pull이 필요한지 판단합니다.

다른 GitHub 계정으로 연결됨

원인학원 PC에 이전 사용자의 GitHub 자격 증명이 남아 있습니다.

확인 순서GitHub 관련 자격 증명과 브라우저 로그인 계정만 확인합니다.

9단계

GitHub Pages로 사이트를 공개합니다

정적 웹사이트(HTML·CSS·JavaScript)는 GitHub에 올린 뒤 저장소 설정에서 Pages를 켜면 누구나 볼 수 있는 주소가 생깁니다. 별도 서버 없이 무료로 공개할 수 있습니다.

1
GitHub에 올리기
위 과정대로 저장소를 만들고 프로젝트를 push합니다.
2
Pages 설정 열기
저장소 페이지에서 Settings를 누르고 왼쪽 메뉴의 Pages로 이동합니다.
3
브랜치 선택
Source를 Deploy from a branch로 두고 main 브랜치와 /(root) 폴더를 선택한 뒤 Save를 누릅니다.
4
주소 확인
잠시 뒤 https://사용자이름.github.io/저장소이름/ 주소에서 사이트가 열립니다.

화면 캡처 자리GitHub 저장소 Settings의 Pages 화면

화면 캡처 자리Deploy from a branch에서 main·/(root) 선택 화면

배포에서 자주 막히는 부분

이미지·CSS가 안 보입니다

원인주소가 /저장소이름/ 아래에 있는데 경로를 /로 시작하는 절대경로로 썼습니다.

해결이미지, CSS, JS 경로를 ./assets 처럼 상대경로로 바꿉니다.

폴더가 통째로 안 열립니다

원인_로 시작하는 폴더는 GitHub Pages가 기본적으로 무시합니다.

해결프로젝트 루트에 빈 .nojekyll 파일을 추가하고 다시 push합니다.

바뀐 내용이 반영되지 않습니다

원인배포에 시간이 걸리거나 브라우저 캐시가 남았습니다.

해결1~2분 기다린 뒤 새로고침하고, 저장소 Actions에서 배포 상태를 확인합니다.

_로 시작하는 폴더가 있다면

프로젝트 루트에 빈 .nojekyll 파일을 추가하고 다시 push합니다.

.nojekyll 만들기

# 프로젝트 루트에서 빈 .nojekyll 파일 만들기
# macOS / Linux / Git Bash
touch .nojekyll

# Windows PowerShell
New-Item .nojekyll

화면 캡처 자리github.io 주소에서 열린 완성 사이트 화면

10단계

집과 학원 상황을 폴더 두 개로 연습합니다

1
집 역할 폴더
개인 저장소를 연결하고 첫 commit과 push를 완료합니다.
2
학원 역할 폴더
다른 빈 폴더에서 같은 저장소를 clone합니다.
3
학원에서 수정
파일을 수정하고 commit한 뒤 GitHub로 push합니다.
4
집에서 이어서 작업
집 역할 폴더에서 pull해 학원 변경 내용이 들어오는지 확인합니다.

개인 GitHub 과정 완료

pull, commit, push, clone의 차이를 설명할 수 있습니다.
작업 시작 전 pull과 종료 전 push를 실행할 수 있습니다.
학원 자리 변경 시 clone과 pull 중 무엇을 써야 하는지 판단할 수 있습니다.
작성자 정보와 GitHub 로그인 계정을 따로 확인할 수 있습니다.

팀 Git

팀 프로젝트는 한 가지 작업 방식을 정하고 끝까지 지킵니다

팀원이 모두 main에서 바로 작업하면 가장 쉽지만 충돌이 잦습니다. 수업 팀 프로젝트에서는 각자 feature/기능명 브랜치에서 작업하고, 팀장 한 명이 main에 합치는 Lv.2 방식을 먼저 권장합니다.

Lv.1 · 가장 쉬움main 직접 작업

모든 사람이 main에서 pull, commit, push를 반복합니다.

혼자 작업하거나 Git을 처음 익힐 때만 사용합니다.

Lv.2 · 추천feature + 팀장 merge

팀원은 자기 feature 브랜치만 push하고, 팀장 한 명이 main에 합칩니다.

학생 팀 프로젝트에서 가장 이해하기 쉬운 구조입니다.

Lv.3 · 회사 방식develop + PR

feature 작업을 develop에 모으고, 검토가 끝난 내용을 main에 배포합니다.

Pull Request와 rebase까지 함께 익힐 때 사용합니다.

Lv.2 · 추천

팀원은 feature, 팀장은 main

팀원은 main에서 직접 작업하거나 push하지 않습니다. 작업이 끝나면feature/login 브랜치 작업 끝났어요. 머지해주세요.라고 팀장에게 알립니다.

팀원

내 브랜치만 GitHub에 올립니다

첫 push 뒤에는 다음부터 git push만 실행하면 됩니다.

팀원: 작업 저장과 제출 · 1단계
```
git status
```
수정·추가·삭제된 파일과 저장할 준비 상태를 확인합니다.
팀원: 작업 저장과 제출 · 2단계
```
git add .
```
현재 폴더 아래의 변경사항을 다음 커밋에 담을 목록으로 올립니다.
팀원: 작업 저장과 제출 · 3단계
```
git commit -m "feat: 로그인"
```
가방에 담은 변경사항을 '로그인 기능 추가'라는 기록으로 저장합니다.
팀원: 작업 저장과 제출 · 4단계
```
git push -u origin feature/login
```
내 feature/login 브랜치를 GitHub에 처음 올리고, 다음부터 git push만 써도 되도록 연결합니다.

팀장

팀원 브랜치를 main에 합칩니다

팀장은 먼저 최신 main을 받은 뒤, 팀원 브랜치를 가져와 merge하고 main만 push합니다.

팀장: feature 브랜치 merge · 1단계
```
git checkout main
```
팀장이 최종본을 관리하는 main 브랜치로 이동합니다.
팀장: feature 브랜치 merge · 2단계
```
git pull
```
다른 팀원이 먼저 합친 최신 main 내용을 가져옵니다.
팀장: feature 브랜치 merge · 3단계
```
git fetch origin
```
GitHub의 브랜치 정보를 새로 받아옵니다. 내 파일은 아직 바뀌지 않습니다.
팀장: feature 브랜치 merge · 4단계
```
git merge origin/feature/login
```
팀원의 원격 feature/login 작업을 현재 main에 합칩니다.
팀장: feature 브랜치 merge · 5단계
```
git push origin main
```
합쳐진 최종본 main을 GitHub에 올립니다.

다른 팀원의 변경을 내 브랜치에 반영할 때

처음 배우는 단계에서는 rebase보다 git merge main이 이해하기 쉽습니다. 최신 main을 내 feature 브랜치에 합친다고 생각하면 됩니다.

팀원: 최신 main 반영 · 1단계
```
git checkout main
```
최신 내용을 받을 기준 브랜치인 main으로 이동합니다.
팀원: 최신 main 반영 · 2단계
```
git pull
```
GitHub의 최신 main을 내 컴퓨터에 반영합니다.
팀원: 최신 main 반영 · 3단계
```
git checkout feature/login
```
다시 내가 작업 중인 feature/login 브랜치로 돌아갑니다.
팀원: 최신 main 반영 · 4단계
```
git merge main
```
최신 main의 변경사항을 내 feature/login 작업에 합칩니다.

Lv.2 팀 규칙 3개

팀원은 main에서 직접 작업하지 않습니다.
팀원은 자기 feature 브랜치만 push합니다.
main merge는 팀장 한 명만 합니다.

Lv.3 · 회사 방식

develop을 중심으로 Git Flow와 PR을 사용합니다

main은 최종 배포본, develop은 팀 작업을 모으는 브랜치입니다. 각자 feature 브랜치를 만들고 Pull Request로 develop에 합칩니다.

Git Flow: feature 작업 시작 · 1단계
```
git checkout develop
```
팀의 작업 내용을 모으는 develop 브랜치로 이동합니다.
Git Flow: feature 작업 시작 · 2단계
```
git pull
```
다른 팀원의 최신 작업이 반영된 develop을 가져옵니다.
Git Flow: feature 작업 시작 · 3단계
```
git checkout -b feature/login
```
최신 develop을 기준으로 내 기능 작업 브랜치를 만들고 이동합니다.

Git Flow: 작업 저장과 제출 · 1단계
```
git status
```
무엇을 수정했는지와 커밋할 파일을 확인합니다.
Git Flow: 작업 저장과 제출 · 2단계
```
git add .
```
변경된 파일을 이번 커밋에 담습니다. 원하지 않는 파일이 없는지 먼저 status로 확인합니다.
Git Flow: 작업 저장과 제출 · 3단계
```
git commit -m "feat: 로그인"
```
로그인 기능 변경사항을 하나의 기록으로 저장합니다.
Git Flow: 작업 저장과 제출 · 4단계
```
git push -u origin feature/login
```
내 feature/login 브랜치를 GitHub에 올려 Pull Request를 만들 준비를 합니다.

GitHub 웹사이트에서 Pull Request를 만드는 순서

1
저장소 페이지를 엽니다
방금 push한 feature/login 브랜치가 보이면 Compare & pull request를 누릅니다. 버튼이 없으면 Pull requests → New pull request를 누릅니다.
2
합칠 방향을 확인합니다
base: develop, compare: feature/login인지 확인합니다. feature의 작업을 develop에 넣는 방향입니다.
3
제목과 내용을 작성합니다
제목에는 기능을 짧게 적고, 내용에는 바꾼 부분과 직접 확인한 내용을 적습니다.
4
Create pull request를 누릅니다
팀장이나 팀원에게 검토를 요청합니다. 충돌 표시가 나면 먼저 내 브랜치에 최신 develop을 반영합니다.
5
검토 뒤 develop에 merge합니다
승인된 Pull Request만 merge하고, 작업이 끝난 feature 브랜치는 그 뒤에 정리합니다.

다른 팀원의 Pull Request가 develop에 합쳐졌다면, 내 feature 브랜치에 최신 develop을 rebase합니다. rebase 뒤에는 커밋 기록이 바뀌므로 --force 대신 --force-with-lease를 사용합니다.

Git Flow: 최신 develop 반영 · 1단계
```
git checkout develop
```
팀의 최신 작업이 모이는 develop으로 이동합니다.
Git Flow: 최신 develop 반영 · 2단계
```
git pull
```
GitHub의 최신 develop을 내 컴퓨터로 가져옵니다.
Git Flow: 최신 develop 반영 · 3단계
```
git checkout feature/login
```
최신 develop을 반영할 내 작업 브랜치로 돌아갑니다.
Git Flow: 최신 develop 반영 · 4단계
```
git rebase develop
```
내 커밋을 최신 develop 뒤에 다시 쌓아, 내 작업에 팀의 최신 내용을 반영합니다.
Git Flow: 최신 develop 반영 · 5단계
```
git push --force-with-lease
```
rebase로 바뀐 커밋 기록을 안전 확인 후 GitHub에 갱신합니다. 다른 사람의 새 push가 있으면 중단됩니다.

Lv.1 · 가장 쉬움

모두 main에서 작업합니다

혼자 작업하거나 팀이 Git을 처음 배울 때만 사용합니다. 작업 전 git pull을 꼭 실행하고, push가 거절되면 다시 pull로 최신 내용을 합친 뒤 push합니다.

main 직접 작업: 매일 반복 · 1단계
```
git checkout main
```
모두가 함께 쓰는 main 브랜치로 이동합니다.
main 직접 작업: 매일 반복 · 2단계
```
git pull
```
작업 전에 팀원의 최신 변경사항을 먼저 받습니다.
main 직접 작업: 매일 반복 · 3단계
```
git add .
```
내 변경사항을 다음 커밋에 담습니다.
main 직접 작업: 매일 반복 · 4단계
```
git commit -m "feat: 작업 내용"
```
무엇을 바꿨는지 적은 메시지와 함께 변경사항을 저장합니다.
main 직접 작업: 매일 반복 · 5단계
```
git push
```
내 커밋을 GitHub의 main에 올립니다.

main 직접 작업의 한계

충돌이 자주 나고 실수하면 최종본이 바로 영향을 받습니다. 팀 프로젝트는 Lv.2 방식으로 넘어가는 것을 목표로 합니다.

작업이 끝났을 때와 자주 쓰는 확인 명령어

머지가 끝난 feature 브랜치는 팀장이 삭제해도 됩니다. git branch -d는 아직 합치지 않은 브랜치를 지우지 않도록 막아줍니다.

작업 완료: feature 브랜치 정리 · 1단계
```
git checkout main
```
삭제하기 전에 안전한 기준 브랜치인 main으로 이동합니다.
작업 완료: feature 브랜치 정리 · 2단계
```
git branch -d feature/login
```
이미 merge된 내 컴퓨터의 feature/login 브랜치를 삭제합니다. 아직 merge되지 않았다면 Git이 막아줍니다.
작업 완료: feature 브랜치 정리 · 3단계
```
git push origin --delete feature/login
```
GitHub에 남아 있는 feature/login 브랜치도 삭제합니다.
작업 완료: feature 브랜치 정리 · 4단계
```
git fetch --prune
```
GitHub에서 이미 삭제된 브랜치 정보를 내 목록에서도 정리합니다.

팀 Git: 자주 쓰는 확인 명령어 · 1단계
```
git status
```
현재 브랜치와 수정된 파일, 커밋 준비 상태를 확인합니다.
팀 Git: 자주 쓰는 확인 명령어 · 2단계
```
git diff
```
아직 add하지 않은 파일에서 무엇이 바뀌었는지 비교해 봅니다.
팀 Git: 자주 쓰는 확인 명령어 · 3단계
```
git log --oneline
```
커밋 기록을 한 줄씩 짧게 확인합니다.
팀 Git: 자주 쓰는 확인 명령어 · 4단계
```
git branch -a
```
내 컴퓨터와 GitHub에 있는 브랜치를 모두 확인합니다.
팀 Git: 자주 쓰는 확인 명령어 · 5단계
```
git stash list
```
잠시 숨겨 둔 작업 목록을 확인합니다.

git stash는 아직 커밋하지 않은 작업을 잠시 숨기고, git stash pop은 그 작업을 다시 꺼냅니다.

팀 Git: 임시 작업 보관과 복원 · 1단계
```
git stash
```
아직 커밋하지 않은 현재 작업을 잠시 서랍에 넣습니다.
팀 Git: 임시 작업 보관과 복원 · 2단계
```
git stash pop
```
가장 최근에 숨긴 작업을 다시 꺼내 현재 폴더에 적용합니다.