브랜치 전략은 복잡한 이름 규칙부터 정하는 일이 아닙니다. 여러 사람이 같은 저장소에서 작업할 때 변경을 분리하고 검토할 수 있게 만드는 방법입니다. 작은 기능 하나를 고른 뒤 시작부터 병합까지 직접 실습해 보세요.
기준 브랜치에서 작업 범위 정하기
현재 기본 브랜치의 상태를 확인하고, ‘검색 결과가 없을 때 안내문 표시’처럼 검증 가능한 한 작업을 정합니다. 별도 브랜치를 만들면 다른 변경과 분리해 시도할 수 있습니다. Git 공식 브랜치 워크플로 문서는 프로젝트에 맞게 긴 수명·짧은 수명의 브랜치를 선택하는 방법을 설명합니다.
작은 커밋으로 이유 남기기
화면 변경, 테스트 추가, 문서 수정 등 검토 가능한 단위로 기록합니다. 커밋 메시지에는 ‘수정’보다 무엇을 왜 바꿨는지 적습니다. 변경을 올리기 전에 해당 기능의 동작과 기존 기능을 확인하세요.
풀 리퀘스트에서 검토받기
문제, 수정 내용, 테스트 방법, 화면 변화가 있다면 확인 자료를 적습니다. GitHub의 풀 리퀘스트 안내에 따르면 풀 리퀘스트는 한 브랜치의 변경을 다른 브랜치에 합치자고 제안하고 검토하는 공간입니다. 리뷰에서 나온 질문과 수정 이유도 기록하세요.
충돌과 병합 후 정리
다른 변경과 충돌하면 파일의 두 수정 의도를 비교하고 테스트를 다시 실행합니다. 팀이 합의한 병합 방법으로 통합한 뒤 기본 브랜치에서 결과가 동작하는지 확인하세요. 충돌 해결은 Git 오류 대처 가이드에서 이어서 확인할 수 있습니다. 하나의 전략이 모든 팀에 맞는다고 가정하지 말고 규모와 배포 주기에 맞게 조정하세요.