콘텐츠로 이동

02. GitHub: 타임머신 저장소 (Code Vault)

"신뢰받는 개발자는 말로 변명하지 않습니다. 기록(History)으로 증명할 뿐입니다."

1. Why: 코드는 회사의 자산입니다

여러분이 짠 코드는 단순한 텍스트 파일이 아닙니다. 미래의 가치를 담고 있는 '자산(Asset)'입니다. 컴퓨터가 고장 나거나 실수를 했다고 해서 자산이 증발해버린다면? 그건 사업을 할 준비가 안 된 것입니다.

GitHub(깃허브)는 우리의 자산을 보호하는 '디지털 금고'이자, 실수를 만회할 수 있는 '타임머신'입니다. 기록이 남기 때문에 우리는 겁 없이 도전하고, 언제든 되돌릴 수 있습니다.

2. Core Concepts: 두 개의 세계 (Local vs Remote)

가장 중요한 개념입니다. 내 컴퓨터(Local)에서 작업한다고 해서 친구가 바로 볼 수 있는 게 아닙니다. 우리는 두 개의 평행우주를 다루고 있습니다.

2-1. 단절된 두 세상 (Island & Cloud)

  • 🌏 내 컴퓨터 (Local): 나만 볼 수 있는 섬. 인터넷이 끊겨도 작업 가능하지만, 컴퓨터를 잃어버리면 끝입니다.
  • ☁️ 깃허브 (Remote): 전 세계가 공유하는 구름 위의 세상. 여기에 올려야 팀원들이 보고, 영구 백업이 됩니다.

2-2. 온라인 쇼핑 비유 (3단계 저장)

단계 개발 용어 비유 (쿠팡/쇼핑몰) 위치 상태
1. 선택 git add 장바구니 담기 🏠 내 컴퓨터 "이거 살 거야" (찜하기)
2. 결제 git commit 주문 완료 (영수증) 🏠 내 컴퓨터 "샀다!" (환불 가능하지만 아직 배송 안 됨)
3. 배송 git push 우리집 도착 ☁️ 깃허브 "공유 완료" (이제야 남들이 봄)

2-3. The Filter: 출입 금지 구역 (.gitignore) 🚫

"쓰레기까지 클라우드에 올리지 마세요. 비밀번호는 더더욱 안 됩니다."

Git은 기본적으로 내 폴더의 '모든 파일'을 감시하고 추적하려 합니다. 하지만 굳이 깃허브에 올릴 필요가 없거나, 절대 올리면 안 되는 파일들이 있습니다.

이때 필요한 것이 바로 .gitignore (깃이그노어) 파일입니다. 이곳에 적힌 파일들은 Git이 투명인간 취급합니다.

(1) 왜 필요한가요? (3대 금지 품목)

분류 예시 파일 이유
🔐 보안 (Secrets) apikey.txt, .env, password.json [절대 엄금] 해커들이 깃허브를 24시간 스캔합니다. 올리는 순간 서버 털립니다.
🐘 뚱뚱한 파일 (Heavy) node_modules/, venv/, 동영상 원본 우리가 올릴 것은 '소스 코드(레시피)'지, '완제품(요리)'이나 '도구'가 아닙니다. (남들은 npm install로 다시 설치하면 됨)
🗑 시스템 잡동사니 (Junk) .DS_Store (Mac), Thumbs.db (Win) 운영체제가 만드는 임시 파일입니다. 동료들이 보면 "이게 뭐야?" 하고 싫어합니다.

(2) 작성 예시 (Python/Web 개발자용)

프로젝트 최상위 폴더에 .gitignore 라는 이름의 파일(확장자 없음)을 만들고 이렇게 적습니다.

# 1. 가상환경 및 라이브러리 (너무 무거움)
venv/
node_modules/
__pycache__/

# 2. 운영체제 파일 (쓸모 없음)
.DS_Store

# 3. 환경 변수 및 비밀 키 (★가장 중요★)
.env
secret_key.txt
*.pem

🚨 골든 타임: 커밋하기 '전'에 만드세요!

이미 Git이 추적을 시작한 파일(git add를 한 번이라도 한 파일)은 나중에 .gitignore에 추가해도 무시되지 않습니다. 프로젝트를 시작할 때 가장 먼저 .gitignore 파일을 만드는 습관을 들이세요. (만약 늦었다면 git rm --cached 명령어로 추적을 끊어야 하는 번거로움이 생깁니다.)

💡 꿀팁: Toptal Gitignore

일일이 적기 귀찮으시죠? gitignore.io 사이트에 가서 내 언어(예: Python, MacOS, VisualStudioCode)를 입력하면, 완벽한 리스트를 자동으로 만들어줍니다. 복사해서 붙여넣기만 하세요!

3. Communication: 말하지 말고 '이슈'로 남기세요 📝

"카톡으로 '로그인 기능 고쳐줘'라고 하지 마세요. 흘러가는 말은 잊혀집니다. GitHub Issue(이슈)에 박제해야 비로소 '업무'가 됩니다."

코딩을 시작하기 전에 가장 먼저 해야 할 일은 '이슈(Issue)'를 등록하는 것입니다. 이슈는 프로젝트의 '퀘스트 보드(Quest Board)'입니다.

3-1. 이슈의 역할

  1. 할 일 관리 (To-Do): "로그인 페이지 만들기", "메인 배너 수정하기"
  2. 버그 제보 (Bug Report): "회원가입 버튼 누르면 멈춤 현상 발생"
  3. 토론의 장 (Discussion): 기획서나 디자인 시안을 올리고 댓글로 논의

3-2. 이슈 번호의 마법 (#Key)

모든 이슈에는 고유 번호(#1, #2...)가 붙습니다. 이 번호는 코드와 업무를 연결하는 열쇠입니다.

  • Issue #5: "로그인 페이지 디자인 수정"
  • Commit Message: "로그인 버튼 색상 변경 (Ref #5)"
  • Pull Request: "로그인 디자인 완료했습니다. (Closes #5)"

👉 자동화: PR 내용에 Closes #5라고 적으면, 코드가 합쳐질 때(Merge) 이슈 5번이 자동으로 '완료(Closed)' 처리됩니다. (엄청 편합니다!)

🧠 AI Native: 이슈도 AI가 관리합니다

개발 환경(IDE)에 연동된 AI에게 이렇게 말해보세요.

  1. "현재 열려있는 GitHub Issue 목록 보여줘." (할 일 확인)
  2. "#11번 이슈 '메인 페이지 레이아웃' 해결하는 코드를 짜줘." (작업 수행)
  3. "커밋 메시지에 'Fix #11'을 포함해서 작성해줘." (기록 연결)

AI는 단순한 코딩 도구가 아니라, 여러분의 프로젝트 매니저가 될 수 있습니다.

🔗 Notion Integration: 기획서와 동기화

Notion의 기획 보드에 GitHub 이슈 링크를 붙여넣으면 미리보기가 생성됩니다. 더 나아가 Notion 데이터베이스와 GitHub Issues를 동기화하면, 개발 진행 상황이 실시간으로 Notion에 반영됩니다. (Notion 설정 -> 연결 -> GitHub 추가)

4. Advanced Concepts: 브랜치 계급도와 책임자

팀 프로젝트의 핵심은 "누가 합치기(Merge) 버튼을 누를 수 있는가?"입니다.

4-1. 브랜치 3단계 계급도 (Git Flow)

브랜치 이름 계급 (Role) 담당 책임자 규칙 (Rule)
main 임원 (CEO) CTO ⛔️ 절대 접근 금지!

오직 완벽하게 검증된 코드만 존재합니다.
develop 팀장 (Manager) 파트장 🚧 공사 현장

각 팀원의 기능(feature)이 모여서 조립되는 곳입니다.
feature/... 사원 (Member) 나 (Me) 🧪 개인 실험실

내가 마음대로 만들고 부수고 실험하는 곳입니다.

4-2. 권한의 흐름 (Approval System)

sequenceDiagram
    participant Issue as 📝 이슈 (#1)
    participant Me as 👨💻 나 (Feature)
    participant Lead as 👩🏫 팀장 (Develop)

    Note over Issue: 로그인 기능 개발 필요
    Me->>Me: 1. 이슈 확인 후 브랜치 생성
    Me->>Me: 2. 코딩 & 테스트 완료
    Me->>Lead: 3. PR (결재 요청, Closes #1)
    Lead->>Lead: 4. 코드 리뷰 & Merge
    Note over Issue: 이슈 #1 자동 완료(Closed)

5. Practical Guide: 이슈부터 배포까지 (Git Flow 정석)

이제부터 main 브랜치는 '성역'입니다. 건드리지 마세요. 모든 작업은 develop에서 시작해서 develop으로 끝납니다.

Step 0. 신원 확인 (최초 1회 필수)

터미널을 열고 내 명함을 등록합니다. (이걸 안 하면 "누구세요?"라며 커밋을 거부합니다.) 

git config --global user.name "HongGildong"
git config --global user.email "hong@example.com"

Step 0.5. 보안관 배치 (.gitignore)

프로젝트를 시작하기 전에, node_modules나 .env가 깃허브에 올라가지 않도록 미리 차단막을 설치합니다.

  1. 최상위 폴더에 .gitignore 파일을 만듭니다.
  2. node_modules/, .DS_Store 등을 입력하고 저장합니다.
  3. 가장 먼저 커밋합니다: git add .gitignore -> git commit -m "Add gitignore"

Step 1. 퀘스트 등록 (Create Issue)

  1. GitHub 상단 메뉴의 Issues 탭 클릭 -> New issue 클릭.
  2. 제목: [Feat] 메인 페이지 레이아웃 잡기
  3. 내용: 구체적인 작업 내용 작성 (AI에게 초안 작성을 시켜도 좋습니다).
  4. Submit new issue 클릭. -> 번호 확인 (예: #11)

Step 2. 작업대 이동 (Checkout Develop)

  1. VS Code 왼쪽 하단 브랜치 이름 클릭.
  2. develop (또는 origin/develop)을 클릭하여 이동합니다.
    • 주의: main에서 시작하면 안 됩니다!

Step 3. 내 브랜치 생성 (Create Feature)

  1. 현재 브랜치가 develop인지 확인합니다.
  2. develop을 클릭 -> + Create new branch... 선택.
  3. 이름 규칙: feature/issue-번호-설명
    • 예: feature/11-main-layout

Step 4. 작업 및 저장 (Coding & AI Commit)

  1. 열심히 코딩을 합니다.
  2. 왼쪽 소스 제어 탭의 ✨(AI Generate) 버튼 클릭하여 커밋 메시지 작성.
  3. Commit 클릭 -> Publish Branch 클릭.

Step 5. 결재 요청 (PR to Develop)

  1. GitHub 웹사이트 접속 -> Compare & pull request 클릭.
  2. ★중요★ 상단의 화살표 방향을 확인하세요!
    • Base: develop ⬅️ Compare: feature/...
    • (절대 main으로 보내면 안 됩니다!)
  3. 내용 작성(Closes #11) 후 Create pull request.

6. Mini Project: [실습] 깃허브 협업 사이클 (Git Flow 버전)

Mission: develop 브랜치에서 안전하게 합체하고, 완벽해지면 main으로 배포한다!

6-1. 역할 분담 (R&R)

  • 팀장 (Maintainer): 저장소(Repo) 생성, 팀원 초대, 최종 병합(Merge) 담당.
  • 팀원 (Contributor): git clone, 브랜치 생성, 자기 프로필 코드 작성 및 PR 발송.

6-2. [팀장] 본부 설치 (develop 생성)

  1. GitHub 레포지토리 생성 및 팀원 초대.
  2. index.html 생성 후 커밋 (Main 브랜치).
  3. ★중요★ develop 브랜치 만들기:
    • GitHub 레포지토리 상단 브랜치 버튼(main) 클릭.
    • 입력창에 develop 이라고 쓰고 Create branch: develop from main 클릭.
    • 👉 이제 develop 브랜치가 생겼습니다!

6-3. [팀원] 각자 도생 (develop에서 시작)

  1. 복제 (Clone): git clone [주소] -> 폴더 이동.
  2. 작업대 변경: git checkout develop
    • (에러 나면: git fetch 한번 하고 다시 시도)
  3. 브랜치 생성: git checkout -b feature/내이름
    • (이제 내 브랜치는 develop에서 뻗어 나왔습니다)
  4. 코드 수정: index.html 내 라인에 자기소개 작성.
  5. 전송: git add . -> git commit -m "내 이름 추가" -> git push origin feature/내이름

6-4. [전체] 합체 의식 (Merge into Develop)

  1. PR 요청 (팀원):
    • GitHub에서 PR 생성 시 Base: develop 인지 두 번 확인!
  2. 병합 (팀장):
    • feature ➡️ develop 으로 병합(Merge)합니다.
  3. 동기화 (전체):
    • 모든 병합이 끝나면, 모두 터미널에서 develop 최신 버전을 당겨옵니다.
    • git checkout develop
    • git pull origin develop

6-5. [Bonus Stage] 긴급 상황: 충돌(Conflict) 해결하기 💥

"GitHub는 똑똑하지만 독심술사는 아닙니다. 두 사람이 '똑같은 줄(Line)'을 수정하면, 누구 걸 써야 할지 몰라서 멈춰버립니다."

1. 충돌 상황 만들기 (시나리오)

일부러 사고를 내봅시다.

  1. 팀원 A: index.html의 맨 첫 번째 줄을 <title>팀원 A가 지배한다</title>로 바꾸고 PR을 날립니다.
  2. 팀장: 팀원 A의 PR을 Merge 합니다. (현재 develop의 첫 줄은 A의 것)
  3. 팀원 B: (아직 A의 합격을 모르는 상태) index.html의 맨 첫 번째 줄을 <title>팀원 B가 짱이다</title>로 바꾸고 PR을 날립니다.
  4. 팀장: 팀원 B의 PR을 보러 갔더니...
    • 🚨 "Can’t automatically merge" (자동 병합 불가) 메시지가 뜹니다.

2. 해결 방법: VS Code에서 교통정리

충돌 해결의 정석은 "코드를 짠 사람(팀원 B)이 최신 버전을 받아와서 고치는 것"입니다.

(팀원 B의 화면)

Step 1. 최신 정보 가져오기 (Update) 내 브랜치(feature/B)에서 develop의 변경사항(A가 고친 것)을 억지로 가져옵니다.

git pull origin develop

Step 2. 빨간 맛 확인 (VS Code) 터미널에 CONFLICT 경고가 뜨고, 파일이 빨갛게 변합니다. index.html을 열어보세요.

<<<<<<< HEAD (내 코드)
<title>팀원 B가 짱이다</title>
=======
<title>팀원 A가 지배한다</title>
>>>>>>> develop (들어온 코드)

Step 3. 선택의 시간 (Resolve) VS Code가 친절하게 버튼을 띄워줍니다. (글자 위를 보세요)

  • Accept Current Change: 내 거(B)를 살린다.
  • Accept Incoming Change: 들어온 거(A)를 살린다.
  • Accept Both Changes: 둘 다 남긴다.

우리의 결정: 싸우지 말고 Accept Both Changes를 누르거나, 직접 텍스트를 수정해서 <title>우리 모두 짱이다</title>로 바꿉니다.

Step 4. 마무리 (Resubmit) 교통정리가 끝났으면 다시 포장해서 올립니다.

git add .
git commit -m "충돌 해결 완료"
git push origin feature/B

Step 5. 최종 병합 이제 팀장이 다시 GitHub 화면을 보면 "Able to merge" 초록색 버튼이 활성화되어 있습니다. Merge!

🎉 피날레: 배포 (Release)

팀장이 마지막으로 선언합니다. "개발 끝! 배포하자!"

  1. 팀장이 GitHub에서 PR을 하나 더 만듭니다.
  2. Base: main ⬅️ Compare: develop
  3. Merge 버튼 클릭.
  4. 👉 이제야 비로소 main에 코드가 반영되었습니다.