Step 1. GitHub 웹에서 직접 파일 수정하기
먼저 "다른 팀원이 커밋한 상황"을 재현하기 위해 GitHub 웹에서 직접 파일을 수정해 보자.
GitHub 웹에서 README.md 파일을 예를 들어, 다음과 같이 수정한 다음

우측 상단의 "Commit changes..." 버튼을 클릭하고

"Commit directly to the main branch"를 체크하여

변경 사항을 원격 main 브랜치에 직접 커밋한다.
이제 터미널에서 다음 명령어를 입력하여 커밋 기록을 확인해 보면

웹에서 커밋한 내용이 로컬에 아직 반영되지 않은 것을 볼 수 있다.
다음 명령어를 입력하여 원격 저장소의 최신 상태를 가져온다.
git fetch
"가져오기만" 한다. (내 브랜치는 안 건드림)
그 다음 Git Graph를 확장 도구를 이용하여 확인해 보면

"원격 main이 내 로컬 main보다 앞서 나간 상황" 임을 확인할 수 있다.
여기서 origin/main은 "내가 마지막으로 확인한 시점의 원격 main 상태"를 기억하는 포인터로 로컬 main과는 별개의 이름표이다.
이제 다음 명령어를 입력하여 원격 main 브랜치를 내 로컬 main에 병합해 보자.
git merge origin/main
+ 위의 fetch 와 merge 과정을 한번에 진행하려면 다음과 같이 명령어를 입력하면 된다. (fetch + merge = pull)
git pull
Git Graph 를 확장 도구를 통해 확인해 보면

내 로컬 main 브랜치가 원격 main 브랜치와 같은 선상에 있는 것을 확인할 수 있다.
이제 로컬에서 README.md 파일을 확인해 보면

원격 저장소 GitHub에서 커밋한 내용이 로컬 저장소에도 반영된 것을 확인할 수 있다.
Step 2. 협업의 기본 리듬을 알아보자
프롤로그
git pull # 내 개발 환경을 최신 상태로 맞추기
git switch -c feature/새기능 # 브랜치 파기
작업 시작 전에는 항상 pull부터!
작업
### ...작업중...
### ...작업중...
### ...작업중...
에필로그
git add .
git commit -m "메시지" # 커밋
git push -u origin feature/새기능 # 브랜치째 올리기
Step 3. Pull Request 만들어보기
Pull Request(PR)는 개발자가 별도의 브랜치에서 작업한 코드 변경 사항을 프로젝트의 기준 브랜치(예를 들어, main)에 반영(Merge)해 달라고 요청하는 기능이다.
직관적으로는 "내가 수정한 코드를 검토한 뒤 메인 코드베이스로 당겨가 달라(Pull)"고 협업 동료들에게 공식 요청을 보내는 것이다.
먼저 나의 실습 프로젝트 개발 환경을 최신화한 뒤 새로 별도의 브랜치를 하나 생성한다.
git pull
git switch -c feature/readme
생성한 브랜치에서 추가적인 커밋을 진행한다.
# 첫 번째 커밋
echo "## 학습 기록" >> README.md
git commit -am "docs: 학습 기록 섹션 추가"
# 두 번째 커밋
echo "## 학습 기록2" >> README.md
git commit -am "docs: 학습 기록2 섹션 추가"

변경 사항이 커밋된 브랜치를 원격 저장소에 올린다.
git push -u origin feature/readme

이제 원격 저장소에 올린 브랜치를 main 브랜치에 병합해달라고 요청하기 위해 다음 명령어를 입력하여 pr을 생성한다.
gh pr create --fill
- --fill 옵션은 그동안의 커밋 내역을 바탕으로 pr의 제목(Title)과 본문(Body)을 자동으로 채워주는 옵션이다.
- --base <브랜치명> 옵션으로 병합 대상 브랜치를 지정할 수 있다. 현재는 dafault 브랜치가 main 이므로 base 옵션을 생략하면 대상 브랜치가 main 브랜치가 된다.
다음 명령어를 통해 현재 브랜치에 대한 pull request 웹 페이지를 브라우저에서 열어준다.
gh pr view --web
Squash and merge 버튼을 눌러서

작업 브랜치(feature/readme)에 쌓인 여러 커밋을 단일 커밋으로 합쳐서 기본 브랜치(예: main)에 병합한다.
그리고 Confirm squash and merge 버튼을 누르면

PR에 대한 병합이 승인(확정)된다.

그 다음 Delete branch 버튼을 클릭하면 원격 브랜치(feature/readme)가 제거된다.
Step 4. PR 병합 이후 브랜치 정리하기
이제 병합이 완료되었으므로 병합에 사용됐던 작업 브랜치(feature/readme)를 정리하자.
먼저 병합이 반영된 원격 저장소의 최신 상태를 로컬로 가져온다.
git switch main
git pull -p # 병합 결과를 로컬로 가져오기
-p (prune) 옵션은 원격 저장소에서 브랜치가 삭제되었을 때, 로컬에 캐시처럼 남아 있는 origin/브랜치명 (원격 추적 브랜치)을 제거한다.

여기서 Y자형 분기가 일어난 이유는 Squash 병합을 통해 2개의 커밋(학습 기록1~2)이 1개의 커밋으로 압축되어 병합되었기 때문에
해당 압축된 커밋은 완전히 새로운 커밋이고
"docs: 학습 기록2 섹션 추가" 커밋의 이전 조상 커밋은 "docs: 학습 기록 섹션 추가" 커밋인데
새로 압축된 커밋에서는 "docs: 학습 기록 섹션 추가" 커밋에 접근할 수 없기 때문에 그래프가 갈라진 것이다.
이제 다음 명령어를 통해 feature/readme 로컬 브랜치를 정리한다.
git branch -D feature/readme
Git은 Squash 병합 이후 남아있는 두 커밋을 '아직 병합되지 않은 작업물'로 판단하기 때문에 -D(--delete --force) 옵션을 통해 강제로 브랜치를 제거해야 한다.
Git Graph를 확인해 보면

단일 브랜치(main)로 깔끔하게 정리된 것을 확인할 수 있다.
'개발 > Git' 카테고리의 다른 글
| [Git] .gitignore와 커밋 메시지 규칙 (0) | 2026.08.24 |
|---|---|
| [Git] GitHub(원격 저장소) 연결하기 (0) | 2026.08.19 |
| [Git] Branch Merge 충돌 실습 (0) | 2026.08.17 |
| [Git] Branch (0) | 2026.08.17 |
| [Git] Git 기본 사이클 돌려보기 (0) | 2026.08.13 |