TIL - 20260602

juni·2026년 6월 2일

TIL

목록 보기

368/473

0602 풀스택 실무 기초 (6/N): Git, 브랜치 전략과 협업 흐름

✅ 1. Git이란 무엇인가?

Git은 소스코드의 변경 이력을 관리하는 버전 관리 도구입니다.
개발자는 Git을 사용해서 언제, 누가, 어떤 파일을, 왜 수정했는지 기록할 수 있습니다.
단순히 코드를 저장하는 도구가 아니라, 실무에서는 협업, 배포, 롤백, 코드 리뷰, 장애 추적의 핵심 도구로 사용됩니다.

➕ 1-1. Git이 중요한 이유

변경 이력 추적
- 어떤 기능이 언제 추가되었는지 확인할 수 있습니다.
- 장애가 발생했을 때 어떤 커밋 이후 문제가 생겼는지 추적할 수 있습니다.
롤백 가능
- 문제가 생긴 코드를 이전 상태로 되돌릴 수 있습니다.
- 배포 후 장애가 발생했을 때 매우 중요합니다.
협업 가능
- 여러 개발자가 동시에 작업해도 브랜치와 Pull Request를 통해 변경 사항을 관리할 수 있습니다.
배포 자동화와 연결
- GitHub Actions, AWS CodeDeploy, Vercel, Netlify 등은 Git 이벤트를 기준으로 배포를 자동화할 수 있습니다.

✅ 2. Git과 GitHub의 차이

Git과 GitHub는 같은 것이 아닙니다.

구분	설명
Git	내 컴퓨터에서 소스코드 변경 이력을 관리하는 도구
GitHub	Git 저장소를 인터넷에서 관리하고 협업할 수 있게 해주는 플랫폼

Git은 로컬에서도 사용할 수 있습니다.
GitHub는 원격 저장소, Pull Request, Issue, Actions, 코드 리뷰 같은 협업 기능을 제공합니다.

내 컴퓨터 Git 저장소
  ↓ push
GitHub 원격 저장소
  ↓ pull
다른 개발자 컴퓨터

✅ 3. Git의 기본 흐름

Git은 작업 디렉토리, 스테이징 영역, 로컬 저장소, 원격 저장소 흐름으로 동작합니다.

작업 디렉토리
  ↓ git add
스테이징 영역
  ↓ git commit
로컬 저장소
  ↓ git push
원격 저장소 GitHub

➕ 3-1. 작업 디렉토리

실제로 파일을 수정하는 공간입니다.
코드 작성, 파일 추가, 파일 삭제가 여기서 일어납니다.

➕ 3-2. 스테이징 영역

커밋에 포함할 변경 사항을 임시로 올려두는 공간입니다.

git add src/app.ts

모든 변경 사항을 추가할 수도 있습니다.

git add .

➕ 3-3. 커밋

커밋은 변경 사항을 하나의 기록으로 저장하는 작업입니다.

git commit -m "feat: 상담 신청 API 추가"

커밋은 나중에 변경 이력을 추적하는 기준이 되므로 메시지를 대충 쓰면 안 됩니다.

➕ 3-4. 원격 저장소 반영

로컬 커밋을 GitHub 같은 원격 저장소에 올립니다.

git push origin main

✅ 4. 자주 사용하는 Git 명령어

➕ 4-1. 상태 확인

git status

현재 변경된 파일, 스테이징된 파일, 커밋되지 않은 파일을 확인합니다.
Git 작업 전후로 가장 자주 확인해야 하는 명령어입니다.

➕ 4-2. 변경 내용 확인

git diff

아직 스테이징하지 않은 변경 내용을 확인합니다.

git diff --staged

커밋 예정인 변경 내용을 확인합니다.

➕ 4-3. 커밋 로그 확인

git log

커밋 이력을 확인합니다.

git log --oneline

커밋 이력을 한 줄씩 간단하게 확인합니다.

➕ 4-4. 원격 저장소 최신 내용 가져오기

git pull origin main

원격 저장소의 최신 변경 사항을 가져와 현재 브랜치에 반영합니다.

git fetch origin

원격 저장소의 변경 사항을 가져오지만, 현재 브랜치에 바로 합치지는 않습니다.
실무에서는 pull보다 fetch 후 상태를 확인하는 것이 더 안전한 경우도 있습니다.

✅ 5. 브랜치란 무엇인가?

브랜치(Branch)는 독립적으로 작업할 수 있는 코드 흐름입니다.
메인 코드에 바로 작업하지 않고, 기능별로 브랜치를 만들어 작업한 뒤 검토 후 병합합니다.

main
 ├─ feature/login
 ├─ feature/consult-form
 └─ fix/payment-error

➕ 5-1. 브랜치를 사용하는 이유

기능 개발 중인 코드가 운영 코드에 바로 섞이는 것을 막을 수 있습니다.
여러 작업을 동시에 진행할 수 있습니다.
코드 리뷰 후 안전하게 병합할 수 있습니다.
문제가 생기면 특정 브랜치 작업만 되돌리기 쉽습니다.

✅ 6. 브랜치 관련 명령어

➕ 6-1. 브랜치 목록 확인

git branch

로컬 브랜치 목록을 확인합니다.

git branch -a

로컬과 원격 브랜치를 모두 확인합니다.

➕ 6-2. 브랜치 생성

git branch feature/consult-form

새 브랜치를 생성합니다.

git checkout -b feature/consult-form

새 브랜치를 만들고 바로 이동합니다.

git switch -c feature/consult-form

최신 Git에서는 switch 명령어를 사용할 수도 있습니다.

➕ 6-3. 브랜치 이동

git checkout main

git switch main

다른 브랜치로 이동합니다.

➕ 6-4. 브랜치 병합

git checkout main
git merge feature/consult-form

feature/consult-form 브랜치의 변경 사항을 main 브랜치에 병합합니다.

➕ 6-5. 브랜치 삭제

git branch -d feature/consult-form

병합이 끝난 로컬 브랜치를 삭제합니다.

git push origin --delete feature/consult-form

원격 브랜치를 삭제합니다.

✅ 7. 브랜치 네이밍 규칙

브랜치 이름은 작업 목적이 바로 보이도록 작성하는 것이 좋습니다.

prefix	의미	예시
`feature/`	새 기능 개발	`feature/admin-dashboard`
`fix/`	버그 수정	`fix/login-error`
`hotfix/`	운영 긴급 수정	`hotfix/payment-500-error`
`refactor/`	리팩토링	`refactor/consult-service`
`chore/`	설정, 빌드, 기타 작업	`chore/update-dependencies`
`docs/`	문서 수정	`docs/api-guide`

실무에서는 작업 티켓 번호나 이슈 번호를 붙이기도 합니다.

feature/TM-101-consult-form
fix/TM-204-admin-login-error

✅ 8. 커밋 메시지 규칙

커밋 메시지는 변경 이력을 이해하기 쉽게 작성해야 합니다.
나중에 장애 추적, 코드 리뷰, 경력 정리에도 도움이 됩니다.

➕ 8-1. Conventional Commits

많이 사용하는 커밋 메시지 형식입니다.

type: subject

git commit -m "feat: 상담 신청 등록 API 추가"
git commit -m "fix: 관리자 로그인 실패 처리 수정"
git commit -m "refactor: 상담 서비스 로직 분리"

➕ 8-2. 자주 사용하는 type

type	의미
`feat`	새 기능 추가
`fix`	버그 수정
`refactor`	기능 변화 없는 코드 구조 개선
`style`	포맷팅, 세미콜론, 공백 등
`docs`	문서 수정
`test`	테스트 코드 추가/수정
`chore`	빌드, 설정, 패키지 작업
`perf`	성능 개선
`ci`	CI/CD 설정 변경

✅ 9. Pull Request란 무엇인가?

Pull Request(PR)는 작업 브랜치의 변경 사항을 main 또는 develop 브랜치에 병합하기 전에 검토 요청을 보내는 과정입니다.
GitHub에서는 PR을 통해 코드 변경 내용, 코멘트, 리뷰, 테스트 결과를 확인할 수 있습니다.

➕ 9-1. PR을 사용하는 이유

코드 리뷰를 할 수 있습니다.
어떤 작업이 왜 들어가는지 기록할 수 있습니다.
자동 테스트와 빌드를 연결할 수 있습니다.
작업 단위별 변경 사항을 추적할 수 있습니다.
main 브랜치에 바로 push하는 위험을 줄일 수 있습니다.

✅ 10. PR 작성 기준

PR은 단순히 코드를 합치는 요청이 아니라, 작업 내용을 설명하는 문서 역할도 합니다.

➕ 10-1. 좋은 PR 설명 예시

## 작업 내용

- 상담 신청 등록 API 추가
- 전화번호 형식 검증 추가
- 상담 신청 완료 후 문자 발송 로직 연결

## 확인 사항

- 필수값 누락 시 400 반환 확인
- 정상 신청 시 DB 저장 확인
- 관리자 페이지 목록에서 신규 신청 노출 확인

## 영향 범위

- 상담 신청 페이지
- 관리자 상담 관리 페이지
- 문자 발송 API

➕ 10-2. PR 작성 시 포함하면 좋은 내용

작업 목적
변경된 주요 파일
테스트한 내용
영향받는 페이지 또는 API
배포 전 확인할 내용
스크린샷 또는 영상
관련 이슈 번호

✅ 11. Merge, Rebase, Squash

Git에서 브랜치를 합치는 방식은 여러 가지가 있습니다.
실무에서는 프로젝트 규칙에 맞게 선택해야 합니다.

➕ 11-1. Merge

git merge feature/consult-form

브랜치의 커밋 이력을 그대로 유지하면서 병합합니다.
히스토리가 자세히 남지만, 커밋 로그가 복잡해질 수 있습니다.

➕ 11-2. Rebase

git rebase main

현재 브랜치의 커밋을 최신 main 위로 다시 쌓는 방식입니다.
커밋 히스토리를 깔끔하게 만들 수 있지만, 잘못 사용하면 충돌 해결이 복잡해질 수 있습니다.
주의할 점
- 이미 원격에 공유된 브랜치에서 rebase를 함부로 사용하면 다른 사람의 작업에 영향을 줄 수 있습니다.
- 혼자 쓰는 feature 브랜치에서는 비교적 안전하게 사용할 수 있습니다.

➕ 11-3. Squash Merge

여러 커밋을 하나의 커밋으로 합쳐서 main에 병합하는 방식입니다.

feature 브랜치 커밋 5개
  ↓ squash merge
main 브랜치에는 커밋 1개로 기록

작업 단위가 깔끔하게 남습니다.
작은 커밋이 너무 많은 경우 유용합니다.

✅ 12. 충돌 Conflict

충돌(Conflict)은 같은 파일의 같은 부분을 서로 다르게 수정했을 때 발생합니다.
Git이 어떤 코드를 선택해야 할지 자동으로 판단하지 못하는 상황입니다.

➕ 12-1. 충돌 예시

<<<<<<< HEAD
const title = "상담 신청";
=======
const title = "빠른 상담 신청";
>>>>>>> feature/consult-form

HEAD는 현재 브랜치의 코드입니다.
아래쪽은 병합하려는 브랜치의 코드입니다.
개발자가 직접 어떤 코드를 남길지 결정해야 합니다.

➕ 12-2. 충돌 해결 순서

1. 충돌 난 파일 확인
2. 남길 코드 결정
3. 충돌 표시 제거
4. 파일 저장
5. git add
6. commit 또는 merge continue

git status
git add src/components/ConsultForm.tsx
git commit

rebase 중이라면 다음 명령어를 사용할 수 있습니다.

git rebase --continue

✅ 13. Git 실무 흐름 예시

➕ 13-1. 기능 개발 흐름

# 1. main 최신화
git checkout main
git pull origin main

# 2. 기능 브랜치 생성
git checkout -b feature/consult-form

# 3. 기능 개발 후 상태 확인
git status
git diff

# 4. 커밋
git add .
git commit -m "feat: 상담 신청 폼 추가"

# 5. 원격 브랜치 push
git push origin feature/consult-form

# 6. GitHub에서 Pull Request 생성

➕ 13-2. 운영 긴급 수정 흐름

# 1. main 기준으로 hotfix 브랜치 생성
git checkout main
git pull origin main
git checkout -b hotfix/login-500-error

# 2. 문제 수정 후 커밋
git add .
git commit -m "fix: 로그인 500 오류 수정"

# 3. push 후 PR 생성
git push origin hotfix/login-500-error

운영 긴급 수정은 작업 범위를 작게 유지해야 합니다.
긴급 수정 브랜치에 unrelated 작업을 섞으면 배포 위험이 커집니다.

✅ 14. Git에서 자주 하는 실수

➕ 14-1. main 브랜치에 바로 작업

main은 운영 배포와 연결되어 있는 경우가 많습니다.
main에 바로 작업하면 검토 없이 운영 코드가 변경될 수 있습니다.
좋은 습관
- 작업 전 항상 브랜치 확인
- 기능별 브랜치 생성
- PR 후 병합

git branch

➕ 14-2. 커밋에 너무 많은 작업을 한 번에 넣음

하나의 커밋에 기능 추가, 버그 수정, 리팩토링, 포맷팅이 다 섞이면 추적이 어렵습니다.

아쉬운 커밋:
feat: 여러 작업 수정

좋은 커밋:
feat: 상담 신청 등록 API 추가
fix: 전화번호 검증 오류 수정
refactor: 상담 상태 변경 로직 분리

➕ 14-3. .env 파일을 Git에 올림

.env에는 DB 비밀번호, JWT_SECRET, AWS 키 같은 민감정보가 들어갈 수 있습니다.
절대 GitHub에 올리면 안 됩니다.

.env
.env.local
.env.production

대신 필요한 환경변수 이름만 .env.example에 정리합니다.

DATABASE_URL=
JWT_SECRET=
AWS_ACCESS_KEY_ID=
AWS_SECRET_ACCESS_KEY=

➕ 14-4. node_modules를 Git에 올림

node_modules는 패키지 설치 결과물입니다.
용량이 크고, 환경마다 달라질 수 있으므로 Git에 올리지 않습니다.

node_modules
dist
build

➕ 14-5. pull 전에 작업해서 충돌을 키움

오래된 main 기준으로 작업하면 나중에 충돌이 커질 수 있습니다.
작업 시작 전에는 main을 최신화하는 습관이 필요합니다.

git checkout main
git pull origin main

✅ 15. GitHub Actions와 Git 흐름

GitHub Actions는 GitHub에서 특정 이벤트가 발생했을 때 자동으로 작업을 실행하는 기능입니다.
예를 들어 main 브랜치에 push되면 자동으로 빌드와 배포를 실행할 수 있습니다.

➕ 15-1. 자주 사용하는 트리거

on:
  push:
    branches:
      - main

  pull_request:
    branches:
      - main

push: 특정 브랜치에 코드가 올라갔을 때 실행
pull_request: PR 생성 또는 업데이트 시 실행

➕ 15-2. 실무 활용 예시

PR 생성 시 테스트 실행
PR 생성 시 빌드 성공 여부 확인
main 병합 시 자동 배포
린트 검사 자동화
Docker 이미지 빌드
AWS 서버 배포

✅ 16. AI를 활용해 Git 작업할 때 주의할 점

Git 명령어는 잘못 사용하면 작업 이력이 꼬이거나 코드가 사라질 수 있습니다.
AI가 알려준 명령어를 그대로 복사하기 전에 현재 브랜치와 변경 상태를 반드시 확인해야 합니다.

➕ 16-1. AI에게 질문할 때 좋은 방식

현재 Git 상태는 다음과 같아.

- 현재 브랜치: feature/consult-form
- main 최신 변경사항을 내 브랜치에 반영하고 싶음
- 아직 커밋하지 않은 수정 파일 있음
- 원격 브랜치에는 push한 적 있음

이 상황에서 안전하게 진행하는 명령어 순서를 알려줘.
각 명령어가 무슨 역할인지 설명해줘.

➕ 16-2. AI 답변 검증 기준

먼저 git status를 확인하라고 하는가?
커밋하지 않은 변경 사항을 보호하는가?
reset --hard 같은 위험한 명령어를 함부로 쓰지 않는가?
현재 브랜치를 확인하는 단계가 있는가?
원격에 공유된 브랜치에서 rebase 위험성을 설명하는가?
충돌 발생 시 해결 방법을 안내하는가?

✅ 17. 실무 체크리스트

➕ 17-1. 작업 시작 전 체크리스트

현재 브랜치가 어디인지 확인했는가?
main 또는 develop 브랜치가 최신 상태인가?
새 작업 브랜치를 만들었는가?
작업 범위가 명확한가?
관련 이슈 또는 업무 번호가 있는가?

➕ 17-2. 커밋 전 체크리스트

git status로 변경 파일을 확인했는가?
git diff로 실제 변경 내용을 확인했는가?
불필요한 파일이 포함되지 않았는가?
.env, 로그 파일, 빌드 결과물이 포함되지 않았는가?
커밋 메시지가 작업 내용을 설명하는가?

➕ 17-3. PR 전 체크리스트

main 최신 변경 사항과 충돌이 없는가?
로컬에서 빌드가 성공하는가?
주요 기능을 직접 테스트했는가?
PR 설명에 작업 내용과 확인 사항을 적었는가?
영향받는 페이지나 API를 표시했는가?

📌 요약

Git은 소스코드 변경 이력을 관리하는 도구이고, GitHub는 원격 저장소와 협업 기능을 제공하는 플랫폼입니다.
Git의 기본 흐름은 작업 → git add → git commit → git push입니다.
브랜치는 독립적인 작업 공간이며, 기능 개발, 버그 수정, 긴급 수정 작업을 분리하는 데 사용합니다.
커밋 메시지는 변경 이력을 이해할 수 있게 작성해야 하며, feat, fix, refactor, docs, chore 같은 prefix를 사용하면 좋습니다.
Pull Request는 코드 병합 전 검토와 기록을 남기는 중요한 협업 절차입니다.
Conflict는 같은 파일의 같은 부분을 다르게 수정했을 때 발생하며, 개발자가 직접 어떤 코드를 남길지 결정해야 합니다.
.env, node_modules, 빌드 결과물, 로그 파일은 Git에 올리지 않도록 .gitignore로 관리해야 합니다.
AI에게 Git 명령어를 물어볼 때는 현재 브랜치, 커밋 여부, 원격 push 여부를 함께 알려줘야 안전한 답변을 받을 수 있습니다.

juni

이전 포스트

TIL - 20260601

다음 포스트

TIL - 20260602

TIL

0602 풀스택 실무 기초 (6/N): Git, 브랜치 전략과 협업 흐름

✅ 1. Git이란 무엇인가?

➕ 1-1. Git이 중요한 이유

✅ 2. Git과 GitHub의 차이

✅ 3. Git의 기본 흐름

➕ 3-1. 작업 디렉토리

➕ 3-2. 스테이징 영역

➕ 3-3. 커밋

➕ 3-4. 원격 저장소 반영

✅ 4. 자주 사용하는 Git 명령어

➕ 4-1. 상태 확인

➕ 4-2. 변경 내용 확인

➕ 4-3. 커밋 로그 확인

➕ 4-4. 원격 저장소 최신 내용 가져오기

✅ 5. 브랜치란 무엇인가?

➕ 5-1. 브랜치를 사용하는 이유

✅ 6. 브랜치 관련 명령어

➕ 6-1. 브랜치 목록 확인

➕ 6-2. 브랜치 생성

➕ 6-3. 브랜치 이동

➕ 6-4. 브랜치 병합

➕ 6-5. 브랜치 삭제

✅ 7. 브랜치 네이밍 규칙

✅ 8. 커밋 메시지 규칙

➕ 8-1. Conventional Commits

➕ 8-2. 자주 사용하는 type

✅ 9. Pull Request란 무엇인가?

➕ 9-1. PR을 사용하는 이유

✅ 10. PR 작성 기준

➕ 10-1. 좋은 PR 설명 예시

➕ 10-2. PR 작성 시 포함하면 좋은 내용

✅ 11. Merge, Rebase, Squash

➕ 11-1. Merge

➕ 11-2. Rebase

➕ 11-3. Squash Merge

✅ 12. 충돌 Conflict

➕ 12-1. 충돌 예시

➕ 12-2. 충돌 해결 순서

✅ 13. Git 실무 흐름 예시

➕ 13-1. 기능 개발 흐름

➕ 13-2. 운영 긴급 수정 흐름

✅ 14. Git에서 자주 하는 실수

➕ 14-1. main 브랜치에 바로 작업

➕ 14-2. 커밋에 너무 많은 작업을 한 번에 넣음

➕ 14-3. .env 파일을 Git에 올림

➕ 14-4. node_modules를 Git에 올림

➕ 14-5. pull 전에 작업해서 충돌을 키움

✅ 15. GitHub Actions와 Git 흐름

➕ 15-1. 자주 사용하는 트리거

➕ 15-2. 실무 활용 예시

✅ 16. AI를 활용해 Git 작업할 때 주의할 점

➕ 16-1. AI에게 질문할 때 좋은 방식

➕ 16-2. AI 답변 검증 기준

✅ 17. 실무 체크리스트

➕ 17-1. 작업 시작 전 체크리스트

➕ 17-2. 커밋 전 체크리스트

➕ 17-3. PR 전 체크리스트

📌 요약

TIL - 20260601

TIL - 20260604

0개의 댓글