GitHub 협업 Part 2 — PR·충돌·Actions·오픈소스

Part 1의 기초를 마쳤다면 이제 팀 협업의 핵심으로 들어갑니다.
Pull Request, 충돌 해결, 자동화, 오픈소스 기여까지 실전 GitHub입니다.

진행률 0%

Part 2에서 배울 것

Pull Request(PR)로 코드 리뷰 요청하는 법

충돌(Conflict)이 생겼을 때 어떻게 해결하는가

GitHub Actions로 테스트·배포를 자동화하는 원리

오픈소스 프로젝트에 기여하는 방법 (Fork → PR)

GitHub Profile을 포트폴리오로 만드는 전략

✅ Pull Request — 코드 리뷰 문화와 PR 작성법

✅ 충돌 해결 — Conflict가 왜 생기고 어떻게 처리하는가

✅ GitHub Actions — YAML로 CI/CD 파이프라인 이해

✅ 오픈소스 기여 — Fork·Issue·PR 전체 흐름

✅ GitHub 커리어 — 잔디·Profile·Pinned Repository

🔀 협업의 핵심: 코드 변경은 항상 PR을 통해, 리뷰를 받고, main에 병합한다.

← Part 1이 먼저입니다

Git vs GitHub · 저장소 · 워크플로 · 브랜치 기초

📗

섹션 A

Pull Request (PR) — 협업의 문

PR은 "내 브랜치의 변경사항을 main에 합쳐달라"는 공식 요청입니다. 코드 리뷰의 핵심 도구입니다.

🔀 PR이 왜 필요한가 — 비유로 이해

직접 main에 push하는 것은 편집장 검토 없이 기사를 바로 게재하는 것과 같습니다. PR은 "편집 검토 요청"입니다.

❌ main에 직접 push

리뷰 없음 → 버그가 그대로 배포됨
누가 뭘 바꿨는지 논의 기록 없음
롤백이 복잡해짐

✅ PR → 리뷰 → merge

팀원이 코드 검토 → 품질 향상
변경 이유와 토론이 기록에 남음
승인 후 merge → 안전한 배포

🔄 PR 전체 흐름

① 브랜치 생성

feature/login 브랜치 만들기

↓

② commit·push

브랜치에 작업 commit → GitHub push

↓

③ PR 생성

GitHub UI에서 "New Pull Request" 클릭

↓

④ 코드 리뷰

팀원이 댓글·승인·변경 요청

↓

⑤ Merge

승인 후 main에 합병 → 브랜치 삭제

✍️ PR 작성 템플릿 — 좋은 PR이란

## 변경 내용 요약
로그인 기능을 추가했습니다.

## 변경 이유
사용자 인증이 없어 누구나 데이터에 접근 가능한 보안 이슈 해결

## 테스트 항목
- [ ] 정상 로그인
- [ ] 잘못된 비밀번호 입력 시 오류 메시지
- [ ] 세션 만료 처리

## 스크린샷 (UI 변경 시)
(이미지 첨부)

## 관련 이슈
Closes #42

💡 Closes #이슈번호 를 PR 본문에 쓰면, PR이 merge될 때 해당 Issue가 자동으로 닫힙니다.

👁️ 코드 리뷰 — 리뷰어와 작성자

역할	할 일	에티켓
리뷰어	코드 읽고 댓글, Approve 또는 Request Changes	코드를 비판하되 사람을 비판하지 않기
작성자	리뷰 댓글에 답하고 수정 후 Re-request review	방어적이지 않게, 배움의 자세로

# 리뷰 후 수정 → 추가 push하면 자동으로 PR에 반영됨
$ git add .
$ git commit -m "fix: 리뷰 반영 - 에러 처리 추가"
$ git push origin feature/login
# → GitHub PR 페이지에 자동으로 새 commit이 표시됩니다

섹션 B

충돌 (Conflict) 해결

충돌은 같은 파일의 같은 줄을 두 사람이 다르게 수정했을 때 발생합니다. 무섭지 않습니다. 해결하면 됩니다.

💥 충돌이 발생하는 상황

main ●────────────────────● \ / Alice ● (index.html 3번줄 수정) Bob ● (index.html 3번줄 수정) ← 같은 줄 → 충돌!

Alice와 Bob이 동시에 같은 파일의 같은 줄을 수정하고 각자 push하면 → Git이 어느 것을 선택해야 할지 모릅니다.

→

Git는 파일 안에 충돌 표시를 추가하고 사람이 직접 결정하도록 멈춥니다.

🔧 충돌 표시 읽는 법

# 충돌이 발생한 파일 안에 이런 표시가 생깁니다
<<<<<<< HEAD
  <h1>환영합니다</h1>       ← 내(현재 브랜치)의 내용
=======
  <h1>Welcome!</h1>         ← 상대방(merge하려는 브랜치)의 내용
>>>>>>> feature/i18n

# 해결 방법: 둘 중 하나 선택 또는 합치기 → 표시 제거
  <h1>환영합니다 / Welcome!</h1>   ← 직접 수정

🛠️ 충돌 해결 4단계

충돌 파일 확인: git status로 "both modified" 파일 목록 확인

파일 열어서 수정: <<<<<<<, =======, >>>>>>> 표시를 제거하고 원하는 내용으로 수정

해결 완료 표시: git add 파일명 → "충돌 해결했다"는 신호

merge commit: git commit → 충돌 해결 commit이 자동 생성됨

# 충돌 해결 전체 과정
$ git merge feature/i18n
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit.

# index.html 열어서 충돌 구간 수정 후...

$ git add index.html
$ git commit
[main 7f3b2c1] Merge branch 'feature/i18n'

✅ VS Code 사용 시: 충돌 파일에서 "Accept Current" / "Accept Incoming" / "Accept Both" 버튼이 표시됩니다. 클릭 한 번으로 해결 가능!

🛡️ 충돌 예방 습관

✓

작업 전 git pull: 최신 상태에서 시작하면 충돌 빈도가 줄어듭니다.

✓

작은 단위로 자주 commit·push: 변경 범위가 작을수록 충돌 범위도 작아집니다.

✓

같은 파일을 동시에 수정하지 않기: 팀원과 담당 파일을 미리 나눠두세요.

✓

브랜치 수명 짧게: 오래 살아있는 브랜치일수록 main과 차이가 벌어져 충돌이 많아집니다.

섹션 C

GitHub Actions — 자동화의 시작

코드를 push하면 자동으로 테스트 실행, 빌드, 배포가 되도록 만드는 것이 Actions입니다.

⚙️ Actions가 뭔가 — 레시피 비유

Actions는 "어떤 이벤트가 발생하면 어떤 일을 자동으로 해라"는 레시피(YAML 파일)입니다.

개념	설명	예시
Workflow	자동화 전체 레시피 (.yml 파일)	CI/CD 파이프라인 전체
Event	레시피를 실행시키는 방아쇠	push, pull_request, schedule
Job	레시피의 단계 묶음	test, build, deploy
Step	Job 안의 개별 명령	npm install, npm test
Runner	실행 환경 (가상 서버)	ubuntu-latest

📄 실제 Actions YAML 예시 — push하면 자동 테스트

# .github/workflows/ci.yml

name: CI 테스트

on:                        # 어떤 이벤트에 실행할까?
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:                    # Job 이름
    runs-on: ubuntu-latest # 어떤 환경에서 실행?

    steps:
      - name: 코드 체크아웃
        uses: actions/checkout@v3

      - name: Node.js 설치
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: 의존성 설치
        run: npm install

      - name: 테스트 실행
        run: npm test

💡 .github/workflows/ 폴더 안에 .yml 파일을 넣으면 자동으로 Actions가 등록됩니다. PR마다 자동 테스트 결과가 표시됩니다.

🚀 주요 Actions 활용 사례

용도	설명	Event
CI (테스트 자동화)	push·PR 시 자동으로 테스트 실행	push, pull_request
CD (배포 자동화)	main merge 시 자동 서버 배포	push to main
코드 품질 검사	Linter, 코드 포맷 자동 검사	pull_request
정기 작업	매일 자정 데이터 백업·알림	schedule (cron)
GitHub Pages 배포	정적 사이트 자동 빌드·배포	push to main

🔑 Secrets — API Key를 안전하게

Actions에서 외부 서비스 API Key, 배포 서버 비밀번호 등은 Secrets에 등록합니다.

GitHub repo → Settings → Secrets and variables → Actions → New repository secret

YAML 파일에서 ${{ secrets.MY_API_KEY }} 형식으로 참조

⚠️ API Key나 비밀번호를 YAML 파일에 직접 적지 마세요. Secrets를 반드시 사용하세요.

섹션 D

오픈소스 기여하기

남의 프로젝트에 코드를 기여하는 전체 흐름을 배웁니다. Fork→브랜치→PR의 표준 패턴입니다.

🍴 Fork란 무엇인가

Fork는 남의 저장소를 내 GitHub 계정으로 복사하는 것입니다. 원본에 영향을 주지 않고 자유롭게 수정할 수 있습니다.

Fork

남의 저장소를 내 계정으로 복사
내 fork에서 자유롭게 수정 가능
원본 프로젝트에 영향 없음

Clone vs Fork

Clone: 저장소를 내 PC로 다운로드
Fork: 저장소를 내 GitHub 계정으로 복사
오픈소스 기여는 Fork 먼저!

🌐 오픈소스 기여 전체 흐름

Issue 확인: 프로젝트 Issues 탭에서 "good first issue" 라벨 찾기 → 기여하고 싶은 이슈에 댓글

Fork: 원본 저장소에서 Fork 버튼 클릭 → 내 계정에 복사본 생성

Clone & 브랜치: fork된 내 저장소를 clone → feature 브랜치 생성

수정 & commit: 코드 수정 → commit → 내 fork에 push

Pull Request: 원본 저장소에 PR 생성 → 메인테이너가 리뷰 → Merge!

# Fork 후 로컬 설정
$ git clone https://github.com/내계정/fork된저장소.git
$ cd fork된저장소

# 원본 저장소를 upstream으로 등록 (원본 최신화용)
$ git remote add upstream https://github.com/원본계정/원본저장소.git
$ git remote -v
origin    https://github.com/내계정/...   (나의 fork)
upstream  https://github.com/원본계정/... (원본)

# 원본의 최신 내용을 내 fork에 반영
$ git fetch upstream
$ git merge upstream/main

📋 좋은 첫 기여를 찾는 법

라벨	의미	추천 레벨
good first issue	초보자 친화적 이슈	⭐ 첫 기여에 최적
help wanted	도움이 필요한 이슈	⭐⭐ 경험 조금 있을 때
documentation	문서 개선	⭐ 코드 몰라도 기여 가능
bug	버그 수정	⭐⭐⭐ 도메인 이해 필요

✅ 첫 기여는 오타 수정, README 개선, 번역 같은 문서 작업부터 시작하는 것이 좋습니다.

섹션 E

GitHub 프로필 & 커리어 활용

GitHub는 개발자의 살아있는 포트폴리오입니다. 잔디부터 Profile README까지 전략적으로 관리합니다.

🌿 잔디(Contribution Graph) 전략

GitHub 프로필의 녹색 잔디 그래프는 활동량을 시각화합니다.

활동	잔디 카운트?	팁
Public repo commit	✅ 카운트됨	매일 TIL 기록
Private repo commit	✅ 카운트됨 (Settings 설정 시)	설정에서 private 활동 표시 ON
Issue 생성·댓글	✅ 카운트됨	오픈소스 이슈 참여
PR 생성·리뷰	✅ 카운트됨	팀 프로젝트 PR 참여
Star 누르기	❌ 안 됨	Star는 잔디와 무관

📝 Profile README 만들기

자신의 GitHub 아이디와 같은 이름의 저장소를 만들면 프로필에 README가 표시됩니다.

# 특별 저장소: username/username
# 이 저장소의 README.md가 GitHub 프로필에 표시됩니다!

# 안녕하세요 👋 저는 홍길동입니다

## 🔧 기술 스택
![Python](https://img.shields.io/badge/Python-3776AB?style=flat&logo=python)
![JavaScript](https://img.shields.io/badge/JavaScript-F7DF1E?style=flat&logo=javascript)

## 📊 GitHub 통계
![GitHub Stats](https://github-readme-stats.vercel.app/api?username=내아이디)

## 📌 최근 프로젝트
- [프로젝트명](링크) — 한 줄 설명

📌 Pinned Repository — 보여주고 싶은 것 선택

프로필에 최대 6개 저장소를 핀으로 고정할 수 있습니다. 포트폴리오의 첫인상입니다.

✓

완성된 프로젝트를 올립니다. 미완성·빈 저장소는 핀하지 않습니다.

✓

각 저장소에 명확한 Description과 README가 있어야 합니다.

✓

실제로 돌아가는 데모 링크(Vercel, GitHub Pages 등)를 README에 연결하세요.

💜 취업 시 GitHub 프로필은 이력서와 함께 제출하는 경우가 많습니다. 잔디 + Pinned + Profile README = 살아있는 포트폴리오.

🏷️ GitHub 기타 핵심 기능

기능	용도
Issues	버그 리포트, 기능 요청, 할 일 관리. 팀 소통 공간.
Projects	칸반 보드 방식의 이슈·PR 관리. Notion 같은 프로젝트 보드.
Releases	특정 commit에 버전 태그(v1.0.0)를 붙여 공식 릴리스 관리.
Wiki	저장소 전용 문서 사이트. 기여 가이드, 아키텍처 문서 등.
Discussions	Issue보다 자유로운 Q&A·아이디어 토론 공간.

섹션 J

복사용 치트시트 (Part 2)

📋 PR 작업 흐름

# feature 브랜치에서 작업 후 PR 생성
git switch -c feature/기능명
# ... 작업 ...
git add .
git commit -m "feat: 기능명 추가"
git push origin feature/기능명

# GitHub에서 "New Pull Request" 생성
# 리뷰 후 merge → 브랜치 삭제

# 로컬에서 정리
git switch main
git pull origin main
git branch -d feature/기능명

📋 충돌 해결 흐름

# merge 시 충돌 발생
git merge feature/브랜치명
# CONFLICT 메시지 확인

# 충돌 파일 확인
git status

# 파일 열어서 수동 해결:
# <<<<<<< HEAD
# 내 내용
# =======
# 상대방 내용
# >>>>>>> feature/브랜치명
# → 원하는 내용으로 수정하고 표시 제거

# 해결 완료 표시
git add 충돌파일명

# merge 커밋
git commit

📋 오픈소스 기여 흐름

# 1. Fork (GitHub 웹에서)
# 원본 저장소 → Fork 버튼 클릭

# 2. 내 fork 클론
git clone https://github.com/내계정/저장소.git
cd 저장소

# 3. upstream 등록
git remote add upstream https://github.com/원본계정/저장소.git

# 4. 브랜치 생성 후 작업
git switch -c fix/오타수정
# ... 수정 ...
git add . && git commit -m "fix: 오타 수정"
git push origin fix/오타수정

# 5. GitHub에서 원본 저장소로 PR 생성

# 6. upstream 최신화 (나중에 필요할 때)
git fetch upstream
git merge upstream/main

📋 GitHub Actions 기본 템플릿

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
      - run: npm install
      - run: npm test

📋 PR 본문 템플릿

## 변경 내용


## 변경 이유


## 테스트 방법
- [ ] 테스트 항목 1
- [ ] 테스트 항목 2

## 스크린샷


## 관련 이슈
Closes #이슈번호