개발 초보자를 위한 Git 브랜치 전략: feature 브랜치 만들고 Pull Request로 병합까지 따라하기

왜 feature 브랜치를 쓰나요?

한 줄로 요약하면 작업을 격리해서 안전하게 합치기 위해서입니다.

• main 브랜치: 언제든 배포/공유 가능한 “안정 버전”
• feature 브랜치: 기능/수정 단위로 분리된 “작업 공간”
• PR: 변경 내용을 리뷰하고, 충돌을 해결하고, 기록을 남기며 병합하는 “검문소” 이 구조만 지켜도 “누가 언제 무엇을 바꿨는지”가 선명해지고, 실수했을 때 되돌리기도 쉬워집니다.

기본 브랜치 구성 (초보자 추천)

브랜치 이름 규칙

팀마다 다르지만 초보자에게는 아래 정도면 충분합니다.

• main: 기준 브랜치
• feature/기능이름: 새 기능 개발
• fix/버그이름: 버그 수정 예) 로그인 버튼 추가라면 feature/login-button

커밋 메시지 간단 규칙

• 동사로 시작: “Add…”, “Fix…”, “Update…”
• 너무 길게 쓰지 않기
• 한 커밋에는 한 가지 변화 예) Add login button UI

따라하기: feature 브랜치 만들기 → 작업 → PR → 병합

아래는 가장 흔한 시나리오입니다. (GitHub 기준으로 설명하지만, GitLab도 흐름은 거의 같습니다.)

1) 최신 main을 기준으로 시작하기

먼저 내 로컬 main이 최신인지 맞춰줍니다.

git checkout main
git pull origin main

2) feature 브랜치 만들고 이동하기

git checkout -b feature/login-button

이제부터 변경은 이 브랜치에만 쌓입니다. main은 건드리지 않는 게 핵심이에요.

3) 코드 수정 후 상태 확인

예를 들어 index.html에 버튼을 추가했다고 해볼게요.

git status
git diff

• git status: 어떤 파일이 바뀌었는지
• git diff: 무엇이 바뀌었는지

4) 스테이징(add) → 커밋(commit)

git add index.html
git commit -m "Add login button UI"

파일이 여러 개면 git add .도 가능하지만, 초보자는 바뀐 파일을 정확히 찍어서 add하는 습관이 실수를 줄여줍니다.

5) 원격 저장소로 푸시(push)

처음 올리는 브랜치라면 -u 옵션을 붙이는 게 편합니다.

git push -u origin feature/login-button

6) Pull Request(PR) 만들기

원격 저장소 화면에서 보통 “Compare & pull request” 버튼이 뜹니다.

PR 작성 시 꼭 넣으면 좋은 정보:

• 무엇을 했는지(요약)

• 왜 했는지(배경/이슈)

• 테스트 방법(어떻게 확인했는지) 예시)

• 변경 내용: 로그인 버튼 UI 추가

• 확인 방법: 로컬에서 페이지 열고 버튼 노출 확인

• 주의 사항: 동작(클릭 이벤트)은 다음 PR에서 추가 예정

7) 리뷰 반영 후 병합(merge)

리뷰에서 “버튼 클래스명 바꿔주세요” 같은 피드백이 오면, 같은 브랜치에서 수정하고 커밋한 뒤 다시 푸시하면 PR에 자동 반영됩니다.

git add index.html
git commit -m "Update button class name"
git push

승인되면 PR 화면에서 Merge를 눌러 main에 합칩니다. 병합 방식은 팀마다 다르지만, 초보자 팀에서는 보통 다음 중 하나를 씁니다.

• Merge commit: 커밋 이력이 그대로 남음(무난)
• Squash and merge: 여러 커밋을 하나로 합쳐 깔끔함(초보자에게 추천되는 경우 많음)

자주 터지는 문제 3가지와 해결법

1) “내 브랜치가 main보다 오래됐어요”

작업 중 main이 많이 바뀌면 내 브랜치에 main 변경을 반영해야 충돌이 줄어듭니다.

git checkout main
git pull origin main
git checkout feature/login-button
git merge main

충돌이 나면 파일에서 충돌 표시를 정리한 뒤:

git add .
git commit -m "Resolve merge conflict"
git push

2) 잘못된 브랜치에서 작업했어요

실제로 많이 합니다. 당황하지 말고 작업 내용을 커밋한 뒤 브랜치를 옮기는 방식이 안전합니다. (상황에 따라 달라질 수 있어요.) 우선 실수 방지를 위해 git branch로 현재 위치를 자주 확인하세요.

git branch

3) PR이 너무 커졌어요

PR이 커지면 리뷰가 힘들어집니다. 기능을 쪼개서:

• UI PR
• 동작 PR
• 리팩토링 PR 처럼 작은 단위로 나누는 습관이 팀에서도 환영받습니다.

마무리: 초보자에게 가장 중요한 3가지

1. main은 항상 안정적인 상태로 유지하기
2. 기능은 feature 브랜치에서만 작업하기
3. PR에는 “무엇/왜/어떻게 확인”을 남기기 이 흐름만 손에 익으면 협업이 갑자기 편해집니다. 다음 단계로는 PR 템플릿, 코드 리뷰 체크리스트, CI 테스트까지 붙이면 더 단단한 개발 습관이 만들어져요.