개발 초보를 위한 Git 브랜치 전략: feature 브랜치로 안전하게 작업하고 Pull Request로 리뷰받는 기본 흐름

개발을 하다 보면 “내가 고친 코드 때문에 다른 기능이 깨지면 어떡하지?”라는 불안이 따라옵니다. 특히 초보일수록 메인 브랜치에 바로 커밋했다가 되돌리느라 시간을 날리는 일이 흔해요. 여기서 가장 간단하고 효과적인 해결책이 feature 브랜치 + Pull Request(PR) 리뷰 흐름입니다. 팀 개발은 물론, 혼자 개발해도 실수가 줄고 작업이 깔끔해집니다.

왜 feature 브랜치가 기본인가?

feature 브랜치는 하나의 작업(기능/버그 수정)을 위한 임시 작업공간입니다.

• 메인 브랜치(main)는 항상 안정적인 상태로 유지
• 기능 개발은 분리된 브랜치에서 진행 → 실패해도 메인에 영향 없음
• PR을 통해 변경 내용을 한 번 더 점검(리뷰, 테스트)하고 합치기 초보에게 특히 좋은 이유는, 작업 단위가 작아져서 실수의 범위가 좁아지고, “내가 뭘 변경했는지”가 명확해지기 때문입니다.

기본 브랜치 구성: 단순하게 시작하기

처음에는 다음 정도면 충분합니다.

• main: 배포/공유 가능한 안정 브랜치
• feature/*: 기능 개발 브랜치 (예: feature/login, feature/todo-ui)
• (선택) fix/*: 긴급 버그 수정 브랜치 브랜치 이름은 “무엇을 하는지”가 보이게 짓는 게 핵심입니다. 개인 프로젝트라도 미래의 내가 봤을 때 이해가 됩니다.

실전 흐름: feature 브랜치 → PR → 머지

1) 최신 main에서 브랜치 만들기

작업 전에 main을 최신으로 맞추고, 그 상태에서 브랜치를 딴다(파생한다)고 생각하면 쉽습니다.

git switch main
git pull origin main
git switch -c feature/login

2) 작업하고, 의미 있는 단위로 커밋하기

커밋은 “나중에 되돌리거나 리뷰할 수 있는 단위”로 쪼개는 게 좋습니다.

git add .
git commit -m "Add login form UI"
git commit -m "Connect login API and handle errors"

팁: 커밋 메시지는 무엇을 했는지가 바로 보이게 동사로 시작하면 읽기 편합니다.

3) 원격 저장소로 푸시하고 PR 만들기

git push -u origin feature/login

이후 PR을 만들 때는 설명에 다음을 넣으면 리뷰가 빨라집니다.

• 변경 요약: 무엇을 왜 바꿨는지
• 테스트 방법: 어떻게 확인했는지
• 영향 범위: UI/서버/DB 등 어디가 바뀌는지

4) 리뷰 반영 후 업데이트 커밋

리뷰에서 “여기 함수가 너무 길어요”, “예외 처리 추가해 주세요” 같은 피드백이 오면 수정하고 같은 브랜치에 추가 커밋을 올리면 됩니다.

git add .
git commit -m "Refactor login handler and add edge cases"
git push

5) 머지 후 브랜치 정리

머지가 끝나면 feature 브랜치는 보통 삭제합니다. 작업이 끝난 브랜치를 남겨두면 브랜치 목록이 금방 복잡해져요.

git switch main
git pull origin main
git branch -d feature/login

원격 브랜치 삭제는 보통 PR 머지 과정에서 옵션으로 처리되기도 합니다.

자주 겪는 상황과 안전한 해결법

main이 앞으로 가버렸을 때: 내 브랜치에 최신 main 반영하기

다른 사람이 main에 머지해 내 브랜치가 뒤처질 수 있습니다. 이럴 때는 보통 main을 내 브랜치에 합쳐서 충돌을 해결합니다.

git switch feature/login
git fetch origin
git merge origin/main

충돌이 나면 당황하지 말고, 충돌 파일을 열어 <<<<<<, ======, >>>>>> 구간을 정리한 뒤 다시 커밋하면 됩니다.

“PR이 너무 커요”라는 말이 나올 때

초보가 가장 많이 하는 실수 중 하나가 PR에 변경을 한꺼번에 담는 겁니다. 예를 들어 로그인 기능을 만든다면:

• PR1: UI 추가
• PR2: API 연결
• PR3: 예외 처리/리팩터링 이런 식으로 쪼개면 리뷰도 쉬워지고, 문제가 생겼을 때 롤백도 간단합니다.

초보를 위한 PR 체크리스트(이것만 지켜도 퀄리티가 올라갑니다)

브랜치가 main에서 최신 상태로 분기됐는가

커밋이 작업 단위로 나뉘어 있는가

PR 설명에 변경 이유/테스트 방법이 있는가

불필요한 파일(로그, 임시 파일)이 포함되지 않았는가

스스로 한 번은 전체 변경(diff)을 읽어봤는가

마무리: “안전한 작업 루틴”이 실력을 키웁니다

feature 브랜치로 작업하고 PR로 리뷰받는 흐름은 단순히 팀 문화가 아니라, 개발 초보가 실수 없이 성장하는 장치입니다. 처음엔 번거롭게 느껴져도, 익숙해지면 오히려 속도가 빨라집니다. 다음 작업부터는 main에 바로 커밋하는 대신, 작은 feature 브랜치 하나부터 만들어 보세요.