GitHub 초보 가이드｜Issue → Branch → Commit → Push → PR → Merge 한 번에 이해하기

GitHub를 공부하다 보면 이런 문장을 자주 만나게 됩니다.

이슈로 문제를 기록하고, 수정용 브랜치를 만들어 작업한 뒤 PR로 검토한다.

처음 보면 Issue, Branch, PR이 각각 무엇인지도 어렵고, 특히 “PR로 검토한다”는 표현이 가장 이해하기 어렵습니다.

하지만 전체 흐름을 하나의 작업 과정으로 보면 생각보다 단순합니다.

전체 흐름

Issue → Branch → 수정 → Commit → Push → PR → Merge

1. Issue는 무엇일까?

GitHub의 Issue는 쉽게 말하면 버그, 해야 할 일, 개선사항 등을 기록하는 작업표입니다.

예를 들어 홈페이지에서 다음과 같은 문제가 발견됐다고 해보겠습니다.

문제
로그인 버튼을 누르면 화면이 멈춘다.

GitHub에 다음처럼 Issue를 만들 수 있습니다.

Issue #35

제목:
로그인 버튼 클릭 시 화면 멈춤

내용:
로그인 버튼을 누르면
화면이 멈추는 현상이 발생함.

여기서 중요한 점은 아직 코드를 수정한 것은 아니라는 것입니다.

Issue는 단순히 “이런 문제가 있으니 나중에 해결해야 한다.” 라고 기록하는 단계입니다.

2. Branch는 왜 만들까?

현재 정상적으로 동작하는 프로그램이 main 브랜치에 있다고 해보겠습니다.

문제를 고치기 위해 곧바로 main을 수정하면, 수정 과정에서 새로운 오류가 발생했을 때 정상 코드까지 영향을 받을 수 있습니다.

그래서 보통 별도의 작업 공간인 Branch를 만듭니다.

main
 │
 ├──────── fix-login
 │              ↑
 │         여기에서 수정

위의 fix-login은 개발자가 임의로 정한 브랜치 이름입니다.

Codex 같은 AI 코딩 도구에게도 다음처럼 요청할 수 있습니다.

Issue #35를 해결하기 위한 브랜치를 만들고 작업해.

이렇게 하면 정상 운영 중인 main과 수정 작업을 분리할 수 있습니다.

3. Commit은 무엇일까?

브랜치에서 코드를 수정했다면 그 변경 내용을 Git에 기록합니다. 이것이 Commit입니다.

Commit은 단순히 “수정했다”라는 글만 남기는 것이 아니라, 그 시점의 변경 내용을 Git의 이력으로 기록하는 것입니다.

예

로그인 오류 수정
입력값 검사 기능 추가
오류 메시지 처리 개선

단, Commit했다고 GitHub에 올라가는 것은 아닙니다.

4. Push는 무엇일까?

로컬 Git에 만들어진 Commit을 GitHub 같은 원격 저장소로 보내는 작업이 Push입니다.

Commit = 내 작업 환경의 Git에 기록
Push = 그 기록을 GitHub로 전송

따라서 다음과 같은 상태도 가능합니다.

수정 완료
↓
Commit 완료
↓
Push 안 함

결과:
로컬 Git에는 있음
GitHub에는 아직 없음

5. PR이 가장 중요하다

이제 수정도 끝났고 GitHub에 Push까지 했다고 하겠습니다.

하지만 아직 main에는 수정 내용이 들어가지 않았습니다.

이때 등장하는 것이 PR입니다.

PR = Pull Request

“제가 이 브랜치에서 이렇게 수정했습니다.
변경 내용을 확인해보고 괜찮으면 main에 합쳐 주세요.”

즉, PR은 단순히 코드를 보내는 기능이 아니라 변경 내용을 검토하고 병합 여부를 결정하는 공간이라고 이해하면 됩니다.

6. “PR로 검토한다”는 뜻

PR을 열면 GitHub가 기존 코드와 수정된 코드의 차이를 보여줍니다. 이를 diff라고 합니다.

- 기존 코드
+ 새 코드
+ 추가한 코드

예를 들어 PR 화면에 다음과 같이 표시될 수 있습니다.

Files changed: 4
+51 −3

이 뜻은 다음과 같습니다.

• 4개의 파일이 변경됨
• 코드 51줄이 추가됨
• 코드 3줄이 삭제됨

즉 오류 51개라는 뜻이 아닙니다.

PR에서는 이런 변경 내용을 보고 “이 수정이 적절한가?”, “다른 기능을 망가뜨리지는 않는가?”를 검토합니다.

7. PR과 Merge는 전혀 다르다

PR을 만들었다고 해서 수정 코드가 자동으로 main에 들어가는 것은 아닙니다.

PR은 어디까지나 검토 단계입니다.

검토 후 문제가 없다고 판단되면 Merge를 실행합니다.

PR = 합치기 전 검토

Merge = 실제로 main에 합치는 작업

8. 전체 흐름을 다시 정리하면

단계	의미
Issue	문제나 해야 할 일을 기록
Branch	main과 분리된 작업 공간 생성
수정	실제 코드 변경
Commit	변경 내용을 Git 이력에 기록
Push	Commit을 GitHub에 업로드
PR	변경 내용을 검토하고 병합을 요청
Merge	검토가 끝난 코드를 main에 반영

9. 그림처럼 보면 더 쉽다

Issue
문제 발견·기록
   ↓
Branch
별도 작업 공간 생성
   ↓
코드 수정
   ↓
Commit
변경 이력 기록
   ↓
Push
GitHub에 업로드
   ↓
PR
변경 내용 검토
   ↓
Merge
main에 반영

10. 혼자 개발해도 PR이 필요할까?

혼자 개발한다면 반드시 PR을 사용해야 하는 것은 아닙니다.

간단한 프로젝트라면 수정 → Commit → Push 방식으로도 충분히 개발할 수 있습니다.

하지만 Codex 같은 AI 코딩 도구에게 많은 작업을 맡긴다면 PR 방식은 상당히 유용합니다.

AI가 코드를 수정한 뒤 바로 main에 넣는 것보다 별도 브랜치에서 작업하게 하고 PR을 생성하면 AI가 무엇을 수정했는지 사람이 먼저 확인할 수 있기 때문입니다.

Codex에게 이렇게 요청할 수 있습니다.

Issue #35를 해결하는 브랜치를 만들고 작업해.
수정이 끝나면 Commit하고 Push해.
그다음 PR을 생성해.
main에는 직접 Merge하지 마.

이렇게 요청하면 AI가 수정 작업을 수행하더라도 최종 반영 여부는 사람이 결정할 수 있습니다.

11. 초보자가 가장 많이 헷갈리는 부분

상황	main에 반영?
Commit만 함	아니오
Push까지 함	아니오
PR 생성함	아니오
PR 검토 후 Merge함	예

마무리

GitHub의 Issue, Branch, PR 같은 용어는 각각 따로 외우면 복잡합니다.

하지만 하나의 흐름으로 보면 간단합니다.

문제를 기록하고
↓
안전한 별도 공간에서 수정하고
↓
수정 내용을 GitHub에 올린 뒤
↓
PR에서 확인하고
↓
괜찮으면 main에 Merge한다.

특히 PR은 “코드를 합치는 기능” 자체라기보다, 코드를 합치기 전에 변경사항을 검토하는 과정이라고 기억하면 이해가 훨씬 쉽습니다.