01 — GIT BASICS

Git 기초 & 영역

Git은 파일 변경 이력을 관리하는 분산 버전 관리 시스템입니다. Working Directory, Staging Area, Local Repository, Remote Repository 네 영역을 통해 코드 변경사항을 추적·공유합니다.

GIT 4대 영역
Working Directory
📁
파일을 수정하는 공간
git add
→
(스테이징)
Staging Area
📋
커밋 대기 중인 변경
git commit
→
Local Repository
🗄️
커밋 히스토리
git push ↑
⇄
↓ git pull
Remote Repository
☁️
GitHub / GitLab 등
git status
On branch main
nothing to commit, working tree clean
주요 명령어 레퍼런스
git init새 저장소 초기화
git clone원격 저장소 복제
git add변경사항 스테이징
git commit스냅샷으로 저장
git push원격 저장소로 업로드
git pullfetch + merge 결합
git fetch변경사항 가져오기만
git status현재 상태 확인
git log커밋 히스토리 조회
git diff변경사항 비교
02 — BRANCH & MERGE

브랜치 & 병합

브랜치는 독립적인 작업 흐름을 만들어 여러 기능을 병렬로 개발할 수 있게 합니다. Merge는 두 브랜치를 합치고, Rebase는 커밋을 재배치하여 히스토리를 선형으로 만듭니다.

● main ● feature ⬡ HEAD 현재 브랜치: main
main: C1 → C2 → C3  |  HEAD → main
feature 브랜치를 생성해보세요.
MERGE
두 브랜치를 합쳐 머지 커밋을 생성합니다.
히스토리가 다이아몬드 형태로 남아 비선형이 됩니다.
장점: 실제 병합 이력이 보존됩니다.
REBASE
커밋을 base 브랜치 위에 재배치합니다.
히스토리가 선형으로 정렬됩니다.
주의: 공유 브랜치에선 사용 금지.
03 — CONFLICT & CHERRY-PICK

충돌 해결 & Cherry-pick

같은 파일의 같은 부분을 두 브랜치가 다르게 수정하면 충돌(conflict)이 발생합니다. Cherry-pick은 특정 커밋만 선택적으로 다른 브랜치에 적용하는 기법입니다.

MERGE CONFLICT
충돌 파일 내용
// app.js
function greet(name) {
<<<<<<< HEAD
return `안녕하세요, ${name}!`;
=======
return `Hello, ${name}!`;
>>>>>>> feature/i18n
}
✓ 충돌 해결됨 — merge commit 생성
충돌 상태 설명
CONFLICT (content): Merge conflict in app.js

<<<<<<< HEAD — 현재 브랜치 내용
======= — 구분선
>>>>>>> feature — 병합 브랜치 내용

원하는 내용을 선택하고 마커를 제거하세요.
CHERRY-PICK
feature 브랜치의 특정 커밋(C4)만 main 브랜치에 적용합니다. 커밋이 복사되어 새 해시(C4')로 적용됩니다.
$ git cherry-pick <commit-hash>
feature 브랜치의 C4 커밋을 선택할 수 있습니다.
GIT STASH
작업 중인 변경사항을 임시로 저장(stash)하고 나중에 복원할 수 있습니다. 급히 다른 브랜치로 전환할 때 유용합니다.
WORKING DIRECTORY
feature.js (수정됨)
utils.js (수정됨)
STASH
(비어있음)
현재 변경사항이 있습니다. "작업 중단"으로 stash에 저장하세요.
04 — WORKFLOW & COLLABORATION

Git 협업 전략

팀의 규모와 배포 전략에 따라 적합한 Git 워크플로우를 선택합니다. GitHub Flow는 단순하고 빠르며, Git Flow는 체계적이고, Trunk Based는 지속적 배포에 최적화됩니다.

사용 시기
소규모~중간 팀
지속적 배포(CI/CD) 환경
단일 프로덕션 버전 유지
SaaS, 웹 서비스
장점
매우 단순한 규칙
빠른 배포 사이클
PR 기반 코드 리뷰
단점
여러 프로덕션 버전 관리 어려움
릴리즈 스케줄링이 없음
사용 시기
버전이 명확한 소프트웨어
정기 릴리즈 일정이 있는 프로젝트
대형 팀 / 엔터프라이즈
모바일 앱, 패키지 라이브러리
장점
체계적인 릴리즈 관리
hotfix, release 분리
명확한 브랜치 역할
단점
복잡한 브랜치 구조
CI/CD에 부적합
배포 사이클이 느림
사용 시기
고성능 엔지니어링 팀
하루 여러 번 배포하는 환경
Feature Flag 사용 가능 시
Google, Meta 등 빅테크
장점
최소한의 브랜치 복잡도
머지 충돌 최소화
빠른 피드백 루프
단점
강한 CI/CD 인프라 필요
Feature Flag 관리 필요
미완성 코드 노출 위험
PULL REQUEST / CODE REVIEW 흐름
🍴
Fork
→
🌿
feature
branch
→
✏️
코드 작성
& 커밋
→
📬
PR 생성
→
👀
Code
Review
→
✅
승인
Approve
→
🔀
Merge
커밋 메시지 컨벤션
feat:
새로운 기능 추가
fix:
버그 수정
docs:
문서 변경
style:
코드 포맷팅 (로직 변경 없음)
refactor:
코드 리팩터링
test:
테스트 코드 추가/수정
chore:
빌드/설정 등 기타 변경
perf:
성능 개선
좋은 vs 나쁜 커밋 메시지
GOOD
feat: 사용자 로그인 기능 구현
fix: 결제 금액 소수점 오류 수정
refactor: API 응답 처리 함수 분리
docs: README 설치 가이드 업데이트
BAD
수정함
WIP
fix bug
asdfgh
좋은 커밋 메시지는 무엇을(what)이 아닌 왜(why)를 설명합니다. 컨벤션을 따르면 자동 changelog 생성, 빠른 코드 리뷰, 이슈 트래킹이 용이해집니다.