Git & GitHub

엄수현·2025년 9월 24일

1. git

버전 관리 도구
👉 파일의 변경 이력을 저장하고 관리하는 도구
👉 누가, 언제, 무엇을, 왜 수정했는지 추적 가능
👉 이전 버전으로 되돌리기 가능

-> "코드 관리"

git 의 3가지 관리 영역

Working Directory → Staging Area → Repository

단계	설명
Working Directory	내가 코드 수정하는 공간
Staging Area	커밋할 파일을 고르는 공간
Repository	커밋들이 저장되는 공간

*커밋: 지금 이 상태를 하나의 버전으로 남기겠다!

.gitignore

프로젝트내에서 git이 무시하도록 설정하는 파일

프로젝트에는 이런 파일들이 있다:
node_modules/
.env (비밀번호, API 키)
로그 파일

이런 걸 GitHub에 올리면?
❌ 용량 터짐
❌ 보안 문제
그래서 .gitignore로 제외시킴.

사용법:
프로젝트 최상단에 파일 생성
.gitignore

안에 이렇게 적는다
node_modules/
.env
*.log

실제 사용 예시를 살펴보면
touch .gitignore
내용 작성 후 저장

git add .gitignore
git commit -m "add gitignore"

branch

1️⃣ 처음 상태
처음에는 이렇게 하나의 브랜치만 존재한다.

A --- B --- C (main)

2️⃣ 브랜치를 만드는 순간
새 브랜치(login)를 생성하면,
login은 기존 브랜치(main)의 마지막 커밋(C)을 함께 가리킨다.

이 시점에서는 아직 코드가 갈라진 것이 아니다.
두 브랜치가 같은 커밋을 보고 있는 상태이다.

A --- B --- C
              ↑
         main  login

3️⃣ 새 커밋을 만들면

이 순간부터 브랜치가 갈라진다.

A --- B --- C (main)
            \
             D (login)

이렇게 하면,

main은 그대로 유지
login 브랜치에서 독립적인 작업 가능
작업 완료 후 merge 가능

merge

브랜치에서 작업한 내용을 다른 브랜치에 합치는 것

보통 이런 흐름으로 작업한다:

main 브랜치에서 서비스 운영
기능 개발을 위해 새 브랜치 생성 (ex. login)
기능 개발 완료

기본 사용법
git switch main
git merge login

-> login 브랜치의 작업 내용을 main 브랜치에 합친다 (main 브랜치로 이동 필요)

그런데 같은 파일의 같은 부분을 서로 다르게 수정했다면??

-> conflict 해결법

원하는 코드만 남기고
git add
git commit

git 기본 명령어

git init git 시작
git add . 워킹 디렉터리 내 모든 파일을 스테이징 영역에 추가( “이거 커밋할 거야” 예약)
git commit -m "메시지" 커밋

git branch 현재 존재하는 브랜치 목록 확인(* 표시가 붙은 브랜치가 현재 위치(HEAD))
git branch login login 브랜치 생성
git switch login login 브랜치로 이동 (HEAD 이동)
git merge login (main으로 이동한 후) login 브랜치 작업 내용을 main에 합치기

git status 상태 확인 (modified, nothing to commit, changes to be committed...)
git log 커밋 기록 보기
git log --oneline --all --graph 모든 브랜치의 커밋을 한 줄씩, 브랜치 구조까지 그림으로 보여줘
git config --global user.name 커밋 작성자 이름 설정 (global에 의해 모든 프로젝트에 적용)
git config --global user.email 커밋 작성자 이메일 설정 (global에 의해 모든 프로젝트에 적용)
git difftool 커밋아이디1 커밋아이디2 두 커밋을 비교해서 보여줌 (j,k로 스크롤, :qa 종료)
-> vscode에서 gui로 확인하는게 더 간편할 수도?

2. github

코드 저장소 (코드를 저장하는 클라우드)
-> "코드 저장"

코드를 github에 올리는 방법

git init
git add .
git commit -m "first commit"

git branch -M main
👉 현재 브랜치 이름을 main으로 강제 변경
(Git 기본 브랜치는 master, GitHub 기본 브랜치는 main이기 때문에 브랜치 이름 맞춰주는 것 -> git push origin master 하면 GitHub에 master라는 브랜치가 새로 생겨버림. 그럼 GitHub에는 main, master 두 개가 생겨서 헷갈릴 수 있음.)

git remote add origin [github 레포지토리 URL]
👉 내 로컬 저장소와 github 저장소 연결 (origin=github 레포지토리 별명)

git push -u origin main 로컬 main 브랜치를 origin 저장소에 같은 이름(main)으로 올려라
cf) -u: upstream 설정
-u는 현재 로컬 브랜치에 대해 upstream을 설정한다.
git push -u origin main은 로컬 main ↔ origin/main을 짝꿍으로 저장해둔 것.
이 설정은 main에만 적용되고, dev에는 아직 설정 안 됨.

그래서 dev에서는 또 한 번 이렇게 해줘야 한다.
git switch dev
git push -u origin dev

이제부터는 dev에서도 그냥
git push
git pull
만 써도 자동으로 origin/dev를 대상으로 동작

요약하면!
main → origin/main
dev → origin/dev
각 브랜치가 자기 짝꿍을 갖게 된다.

git remote -v 로컬과 연결된 원격 저장소 확인 가능

github 기본 명령어

git clone
git clone [github 레포지토리 URL] 원격 저장소를 내 컴퓨터로 복사하는 것
git fork
다른 사람의 GitHub 저장소를 내 GitHub 계정으로 복사하는 것
-> github 사이트에서 버튼 클릭으로 함 (코드 명령어 아님)
git pull
git pull origin main 원격 저장소(origin)의 main 브랜치 최신 내용을 가져와서, 내 로컬 브랜치에 합쳐라

git pull은 내부적으로 이렇게 동작한다

git fetch origin main -> 깃허브에서 최신 코드 가져오고 (fetch)
git merge origin/main -> 그걸 현재 내 브랜치에 합친다 (merge)

🚨 중요 포인트
지금 내가 있는 브랜치에 합쳐진다

지금 내가 dev 브랜치에 있다면?
git pull origin main
-> 깃허브 main을 내 dev 브랜치에 합치는 것!

Issue & PR(Pull Request)

Issue
“해야 할 일”을 기록하는 공간
기능 추가, 버그 수정, 리팩토링 등
-> 모든 작업은 Issue 단위로 관리하는 게 좋다.

예시:
Issue #5: 로그인 기능 구현

<Issue 기반 작업 흐름>
이슈 생성
→ 이슈 해결용 브랜치 생성
이슈를 만들면 보통 이렇게 브랜치를 딴다
git switch -c feature/5-login
👉 브랜치 이름에 이슈 번호 포함
👉 추적이 쉬움

→ 작업 + commit
예:
feat(#5): 로그인 UI 추가
feat(#5): 로그인 API 연결
feat(#5): 로그인 에러 처리

👉 커밋은 작업 과정 기록
👉 이슈 번호를 적어두면 연결됨

→ push
→ PR 생성
→ merge
→ 이슈 닫힘

Pull Request (PR)

“이 브랜치를 기준 브랜치에 합쳐주세요” 요청

PR과 Issue 연결

PR 설명에 Closes #5 라고 적으면

PR이 merge되면 Issue #5 자동으로 닫힘

github 협업

ewhaian 개발 관련 규칙

브랜치 구조
main → 배포용
dev → 모든 기능이 모이는 브랜치
깃허브 레포
upstream -> 팀 레포(원본)
origin -> 내 포크 레포(내 GitHub에 있는 복사본)

기본세팅

팀장: 로컬에서 프로젝트 기본세팅 -> github에 업로드
팀원: 팀장 레포 fork해옴
-> 내 포크 레포를 clone
git clone https://github.com/내아이디/팀레포.git
cd 팀레포
-> upstream(팀 레포) 연결
git remote add upstream https://github.com/팀장(or-org)/팀레포.git

-> 이렇게 하는 이유:

이름	의미	용도
origin	내 포크 레포 (clone하면 자동 연결)	push하는 곳
upstream	팀 레포	최신 코드 받아오는 곳

작업 시작 전

최신 upstream 반영하고 브랜치 파기

팀이 dev로 통합한다면:
git switch dev
git pull upstream dev

내 포크 레포(origin)도 최신 반영하기

git push origin dev

기능 브랜치 생성하기
git branch feature/123-login
git switch feature/123-login
-> git switch -c feature/123-login

작업 루틴: 작업을 쪼개서 작게 커밋하고 내 포크 레포로 push
git add .
git commit -m "feat(#123): 로그인 UI"
git push -u origin feature/123-login
PR 보내기 전에 upstream을 내 브랜치에 먼저 합치기

git switch dev
git pull upstream dev
내 feature 브랜치에 dev를 합치기
git switch feature/123-login
git merge dev

충돌 나면 여기서 해결 → git add . → git commit -> git push

PR 보내기
GitHub에서 PR 생성할 때
base repository: upstream(팀 원본 레포)
base branch: dev
compare: feature/123-login(내 브렌치)
merge 이후
PR이 upstream에 merge되면, 내 로컬/포크 레포도 최신으로 맞춰줘야 함
git switch dev
git pull upstream dev
git push origin dev