전체 개발 노트 모아보기

Git 핵심 작업 영역의 이해

Git이 코드를 다루는 4개의 공간

초보자가 Git을 배울 때 가장 헷갈려 하는 것이 바로 "내가 저장한 코드가 지금 어디에 있는가?" 입니다. Git은 단순한 백업 툴이 아닙니다. 내 코드가 안전하게 서버로 가기까지 거치는 4개의 가상 공간을 완벽히 이해해야만 실무에서 사고를 치지 않습니다.

💡 핵심 비유

작업 영역 (공간)	핵심 비유	상세 설명
Working Dir	💻 코딩하는 책상	여러분이 지금 코드를 짜고 있는 실제 폴더입니다.
Staging Area	📦 택배 상자	배송 보낼 물건(수정된 파일)만 골라서 모아두는 곳입니다.
Local Repo	🏠 내 방 창고	포장이 끝난 상자에 바코드를 붙여(commit) 내 컴퓨터에 안전하게 보관합니다.
Remote Repo	🚚 물류센터 (GitHub)	창고의 짐들을 택배 기사님에게 넘겨 멀리 있는 클라우드 서버로 완전히 보냅니다(push).

0단계: Git 다운로드 및 설치하기

초기 설정을 하기 전에 당연히 내 컴퓨터에 Git 프로그램이 깔려 있어야겠죠? 공식 홈페이지에서 다운로드 받아 설치해 줍니다. 윈도우 사용자의 경우 설치 중 뜨는 수많은 설정 창은 모두 기본값(Next)으로 두고 넘기시면 됩니다.

Windows 용 다운로드 Mac 용 다운로드

[필수] 가장 먼저 해야 할 Git 초기 설정

Git을 설치하고 나서 가장 먼저, 딱 한 번만 해두면 되는 필수 설정입니다. 앞으로 여러분이 택배 상자에 바코드를 붙일 때(commit) "누가 포장했는지" 이름표를 달기 위한 설정입니다.

        
        터미널 (명령 프롬프트 / Git Bash)
      

# 여러분의 닉네임(이름)을 입력하세요.
git config --global user.name "내 닉네임"

# 여러분의 GitHub 가입 이메일을 입력하세요.
git config --global user.email "내이메일@example.com"

# 설정이 잘 되었는지 확인하기
git config --list

⚠️ 주의: 이메일은 반드시 GitHub과 똑같이!

여기서 설정하는 이메일 주소는 반드시 GitHub에 회원가입할 때 사용한 이메일 주소와 똑같아야 합니다. 그래야 나중에 코드를 GitHub으로 보냈을 때(push), 내 계정에 잔디(기여도 그래프)가 초록색으로 예쁘게 심어집니다!

로컬에서 버전 기록하기 (add & commit)

내 컴퓨터에서 찰칵! 버전을 기록하는 방법

인터넷이 끊겨도 Git은 동작합니다. 내 컴퓨터(Local) 안에서 파일의 변경 사항을 추적하고, 의미 있는 단위로 묶어 버전을 생성하는 기초 명령어들을 실무 레벨에서 배웁니다.

1. 필수 기초 명령어 모음

명령어	설명	실무 활용 팁
git init	현재 폴더를 Git 저장소로 초기화	최초 프로젝트 생성 시 딱 한 번만 사용합니다. 숨김 폴더인 `.git`이 생성됩니다.
git status	현재 변경된 파일들의 상태 확인	내가 무슨 파일을 건드렸는지, add나 commit을 하기 전에 습관적으로 쳐야 하는 가장 중요한 명령어입니다.
git add .	모든 변경사항을 스테이징 영역에 추가	변경된 파일 중 원하는 파일만 `git add 파일명` 으로 골라 담을 수도 있습니다.
git commit -m "msg"	스테이징된 파일들을 모아 하나의 버전을 생성	의미 있는 작업 단위별로 잘게 쪼개서 자주 commit 하는 것이 좋습니다.

2. 커밋 메시지 작성 컨벤션

회사에서는 git commit -m "수정함" 처럼 쓰면 욕을 먹습니다. 커밋의 목적을 한눈에 알 수 있게 말머리를 다는 규칙(Conventional Commits)을 따릅니다.

타입 (Type)	설명 및 예시
feat:	새로운 기능 추가 (예: `feat: 카카오 로그인 연동 기능 추가`)
fix:	버그 수정 (예: `fix: 비밀번호 재설정 페이지 무한로딩 버그 수정`)
docs:	문서 수정 (README.md 등)
style:	코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
refactor:	코드 리팩토링 (기능 변화 없이 코드 구조만 개선)
chore:	빌드 테스트 업데이트, 패키지 매니저(npm) 설정 등

GitHub 원격 연동과 백업 (push & pull)

클라우드 서버와 내 컴퓨터의 동기화

내 컴퓨터에만 저장되어 있는 코드를 GitHub라는 거대한 클라우드 저장소(Remote)로 밀어 올리고(push), 동료가 올린 최신 코드를 내 컴퓨터로 끌어오는(pull) 협업의 기초를 배웁니다.

1. 원격 명령어 모음

명령어	설명
git remote add origin [URL]	내 로컬 폴더에 GitHub 원격 저장소 주소를 `origin`이라는 이름표로 연결합니다.
git push origin main	내 컴퓨터에서 `commit`한 버전들을 `origin`(GitHub)의 `main` 브랜치로 업로드합니다.
git pull origin main	GitHub 서버의 최신 `main` 브랜치 코드 변동사항을 다운로드하여 내 컴퓨터의 파일에 병합시킵니다.
git clone [URL]	남이 만들어둔 GitHub 프로젝트나, 내가 출근해서 새 컴퓨터에 세팅할 때 저장소를 통째로 다운로드 받아옵니다.

브랜치 전략 (Merge vs Rebase)

코드를 분리하는 평행우주, 브랜치(Branch)

협업의 핵심은 메인 소스코드를 건드리지 않고, 나만의 독립된 평행우주(브랜치)를 만들어 작업하는 것입니다. 작업이 끝난 브랜치를 다시 메인으로 합치는 두 가지 고급 전략의 차이를 시각적으로 완벽히 마스터합니다.

1. 브랜치(Branch) 필수 명령어

메인 코드(main)에서 가지(branch)를 뻗어 나와 안전하게 새로운 기능을 개발하고, 다시 메인 코드로 합치는 과정에 쓰이는 필수 명령어들입니다.

명령어	설명
git branch	현재 내 로컬에 있는 브랜치 목록을 보여주고, 현재 내가 어떤 브랜치에 있는지 `*` 로 표시해 줍니다.
git branch <이름>	새로운 브랜치를 생성합니다. 단, 생성만 할 뿐 그 브랜치로 바로 이동하지는 않습니다.
git checkout <이름> 또는 git switch <이름>	작업할 브랜치로 이동(전환)합니다. 최근에는 명확성을 위해 `switch` 명령어를 많이 사용합니다.
git checkout -b <이름>	브랜치를 생성함과 동시에 그 브랜치로 즉시 이동합니다. 실무에서 가장 많이 쓰는 단축키입니다.
git merge <이름>	현재 브랜치로 지정한 대상 브랜치의 작업 내역을 병합(합치기)합니다. (예: main에서 `git merge feature` 실행)

2. 브랜치를 병합하는 두 가지 전략

⚠️ Rebase 사용 시 주의사항

이미 원격 저장소(GitHub)에 Push 되어 남들과 공유하고 있는 브랜치에서는 절대로 git rebase를 사용해선 안 됩니다! 히스토리의 해시값이 변경되어 다른 팀원들의 저장소와 치명적인 불일치(Conflict) 폭탄이 발생하게 됩니다.

충돌(Conflict) 해결과 PR 리뷰

무서운 화면을 마주했을 때 대처법

동료와 내가 똑같은 파일의 똑같은 라인을 동시에 수정했다면? 필연적으로 발생하는 Merge Conflict(충돌)을 두려워하지 않고 우아하게 해결하는 방법과, 코드를 안전하게 합치는 Pull Request(PR) 문화를 배웁니다.

충돌(Conflict)이 발생했을 때 나타나는 코드

Git은 코드를 합칠 때 헷갈리면 알아서 판단하지 않고 개발자에게 숙제를 던집니다. 파일 안에 아래와 같은 이상한 텍스트가 삽입됩니다.

<<<<<<< HEAD (내가 짠 현재 코드)
const title = "Minstudio 새로운 웹사이트";
======= (충돌 경계선)
const title = "Minstudio 리뉴얼 버전입니다";
>>>>>>> feature/update-title (상대방이 짠 코드)

💡 우아한 해결 방법

당황하지 말고, <<<, ===, >>> 기호들을 전부 지우세요. 그리고 남기고 싶은 진짜 최종 코드 한 줄만 예쁘게 남겨둔 뒤, 다시 git add . 와 git commit을 해주면 충돌 해결이 끝납니다! 최근의 VS Code 에디터는 버튼 하나로 해결할 수 있는 GUI를 제공합니다.

GitHub Actions CI/CD 마스터

코드를 푸시하면 서버에 자동 배포된다고?

Git의 활용은 코드를 백업하는 것을 넘어, 코드가 GitHub에 도달했을 때 무언가 액션을 취하게 만드는 CI/CD (지속적 통합/배포) 에서 진정한 빛을 발합니다.

1. GitHub Actions 핵심 트리거

이벤트 (Event)	동작 조건	주요 활용 사례
push	특정 브랜치에 코드가 푸시되었을 때	main 브랜치 푸시 시 자동 실서버 배포 (CI/CD)
pull_request	PR이 생성되거나 업데이트되었을 때	코드 병합 전 단위 테스트(Unit Test) 및 린트(Lint) 검사
schedule	크론(Cron) 표현식에 따른 정기적 실행	매일 밤 자정 백업 작업, 주기적인 크롤링
workflow_dispatch	GitHub 페이지에서 수동으로 버튼 클릭	원할 때만 실행하는 수동 릴리스 배포, 수동 트리거

2. 실전: Next.js 배포 파이프라인 (.yml)

      
      .github/workflows/main.yml
    

name: Next.js CI/CD Pipeline

on:
  push:
    branches: [ "main" ]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    
    steps:
    - name: 📦 저장소 코드 체크아웃
      uses: actions/checkout@v4

    - name: ⚙️ Node.js 환경 세팅
      uses: actions/setup-node@v4
      with:
        node-version: '20'
        cache: 'npm'

    - name: 📥 의존성 패키지 설치
      run: npm ci

    - name: 🏗️ Next.js 프로젝트 빌드
      run: npm run build

    - name: 🚀 서버 배포 (예: AWS EC2)
      run: echo "배포 스크립트를 여기에 작성합니다!"

GitHub Actions Console

[1/5] 📦 저장소 코드 체크아웃 ... Done (0s)
[2/5] ⚙️ Node.js 환경 세팅 ... Done (1s)
[3/5] 📥 의존성 패키지 설치 ... Done (5s)
> next build
[4/5] 🏗️ Next.js 프로젝트 빌드 ... Done (14s)
[5/5] 🚀 서버 배포 (예: AWS EC2) ... Done (2s)
🎉 Job "build-and-deploy" completed successfully in 22s.

minstudio