이 글은 2026년 3월 13일 작성된 글입니다.
Git Flow vs GitHub Flow / git pull 동작 원리 정리
Git 협업을 진행할 때 브랜치 전략과 pull / push 동작 방식을
이해하는 것은 매우 중요하다.
이번 학습에서는 Git Flow와 GitHub Flow의 차이, 그리고 git pull의
내부 동작 방식을 정리하고 GitHub 협업 과정(PR, Issue, Merge 등)을 직접
실습해 보았다.
1. Git Flow vs GitHub Flow
Git에는 여러 브랜치 전략이 존재하지만 대표적으로 Git Flow와 GitHub
Flow가 많이 사용된다.
| 구분 | GIT FLOW | GITHUB FLOW |
|---|---|---|
| 브랜치 전략 | 복잡함 (main, develop, feature, release, hotfix) | 단순함 (main, feature) |
| 적합한 분야 | 버전 관리가 필요한 패키지 / 앱 | 지속적 배포가 필요한 웹 서비스 |
| 배포 주기 | 길다 (주 단위, 월 단위) | 짧다 (일 단위, 시간 단위) |
| 장점 | 체계적인 버전 관리 가능 | 빠른 배포와 피드백 가능 |
| 단점 | 프로세스가 복잡하고 느림 | 안정성이 떨어질 수 있지만 자동화 테스트로 극복 가능 |
Git Flow 특징
main
└ develop
└ feature/*
└ release/*
└ hotfix/*대규모 프로젝트나 버전 관리가 중요한 서비스에서 주로 사용된다.
GitHub Flow 특징
main
└ feature/*feature 브랜치를 생성하여 작업 후 Pull Request → 리뷰 → main 병합 →
배포 흐름을 가진다.
주로 지속적 배포(CI/CD)가 필요한 웹 서비스에서 많이 사용된다.
2. git pull 명령어
기본 사용
git pull origin main현재 내가 작업하고 있는 로컬 브랜치에 리모트(origin)의 main 브랜치
내용을 가져와서 적용한다.
병합 방식은 merge이다.
rebase 방식
git pull origin main --rebase현재 로컬 브랜치에 리모트의 main 브랜치 내용을 가져와 적용하지만
병합 방식이 rebase로 동작한다.
3. git pull의 내부 동작 원리
git pull origin main 명령은 내부적으로 다음 두 명령이 순차적으로
실행되는 것과 같다.
1. fetch
git fetch origin main리모트(origin)의 main 브랜치 내용을 로컬 저장소로 가져온다.
2. merge
git merge FETCH_HEAD가져온 내용을 현재 브랜치에 병합한다.
즉 git pull은 아래와 같은 과정이다.
fetch → mergeFETCH_HEAD란?
FETCH_HEAD는 가장 최근에 fetch 명령으로 가져온 브랜치의 최신 커밋을
가리키는 참조(reference)이다.
즉 git fetch를 실행하면 원격 저장소의 데이터를 로컬로 가져오고
그 최신 커밋 정보가 FETCH_HEAD에 기록된다.
4. git pull vs git push 적용 대상 차이
| 구분 | git pull origin main | git push origin main |
|---|---|---|
| 적용 대상 | 로컬의 현재 브랜치에 리모트의 main 브랜치 적용 | 로컬의 main 브랜치를 리모트의 main 브랜치에 적용 |
예시
(현재 브랜치 : test) git pull origin main- test 브랜치에 리모트 main 브랜치 내용이 적용됨
(현재 브랜치 : test) git push origin main- 로컬의 main 브랜치가 리모트의 main 브랜치에 적용됨
- 현재 브랜치가 test이어도 main 브랜치가 push 된다
5. git pull vs git pull --rebase 비교
| 구분 | git pull origin main | git pull origin main --rebase |
|---|---|---|
| 병합 방식 | merge | rebase |
| 커밋 히스토리 | 병합 커밋 생성 → 히스토리 복잡 | 일자형 히스토리 |
| 충돌 해결 | 한 번에 충돌 해결 | 커밋별로 순차적 해결 |
| 장점 | 이력이 보존됨 | 깔끔한 커밋 이력 |
| 단점 | 커밋 히스토리가 복잡해짐 | 이력이 변경됨 |
| 권장 상황 | 동일 파일 작업이 적을 때 | 동일 파일 작업이 많을 때 |
6. GitHub 협업 실습
GitHub 협업 흐름을 직접 실습해 보았다.
실습 내용
- GitHub 리포지토리 생성
- Issue 생성
- Feature 브랜치 생성
- Pull Request 생성
- Pull Request 거부
- Pull Request 승인
- squash merge 진행
GitHub 협업 흐름은 일반적으로 다음과 같다.
Issue 생성
↓
Feature Branch 생성
↓
개발 진행
↓
Pull Request 생성
↓
Code Review
↓
Merge특히 squash merge를 사용하면 여러 커밋을 하나로 합쳐 깔끔한 커밋
히스토리를 만들 수 있다.
✅ 정리
- Git Flow는 복잡하지만 체계적인 버전 관리에 적합
- GitHub Flow는 단순하고 빠른 배포에 적합
git pull은 내부적으로 fetch + merge 과정으로 동작--rebase옵션을 사용하면 커밋 히스토리를 깔끔하게 유지할 수
있음- GitHub 협업에서는 Issue → PR → Review → Merge 흐름이 핵심
느낀 점
Git을 단순한 버전 관리 도구라고 생각했지만
실제로는 협업을 위한 작업 흐름을 관리하는 시스템이라는 것을 느꼈다.
특히 GitHub에서 PR 생성, 리뷰, squash merge 과정을 직접 경험하면서
팀 프로젝트에서 코드가 어떤 흐름으로 관리되는지 이해할 수 있었다.
사실 그동안 독학과 단독 프로젝트 위주로 공부해왔던 나는
익숙하지 않지만, 앞으로 팀 프로젝트를 진행하면서
브랜치 전략과 PR 흐름을 자연스럽게 활용할 수 있도록 익숙해져야겠다.
