‘기업이 선호하는 Git 전략’ 하나가 따로 있는 것은 아닙니다. 제품의 배포 주기와 팀 규모, 검토 방식에 따라 브랜치 규칙이 달라집니다. 면접에서 특정 전략 이름을 외우는 것보다 왜 그 방식을 골랐는지 설명할 수 있어야 합니다.
변경을 얼마나 자주 통합하는가
짧은 기능 브랜치를 자주 합치는 팀과 장기간 유지하는 배포 브랜치가 필요한 팀은 갈등을 다르게 관리합니다. Git 공식 브랜치 워크플로 설명은 긴 수명의 브랜치와 작업 브랜치가 어떻게 쓰이는지 보여 줍니다. 현재 프로젝트의 배포 빈도와 리뷰 소요 시간을 먼저 적으세요.
리뷰와 자동 검사는 어디서 하는가
풀 리퀘스트에서 테스트 결과를 확인하고 변경 이유를 논의할지, 소규모 팀에서 다른 검토 방식을 쓸지 결정합니다. GitHub 풀 리퀘스트 안내는 변경 제안, 리뷰, 검사, 병합의 과정을 설명합니다. 브랜치 이름 규칙보다 검토 없이 코드가 들어가는지 여부가 실습에서 더 큰 차이를 만듭니다.
실습으로 비교하기
같은 작은 기능을 두 방식으로 진행해 보세요. 하나는 짧은 브랜치와 즉시 리뷰, 다른 하나는 여러 변경을 모은 뒤 리뷰합니다. 충돌 횟수, 리뷰하기 어려웠던 이유, 테스트 재실행 여부를 기록하면 팀에 맞는 기준을 만들 수 있습니다. 공유 이력을 강제 푸시로 바꾸는 작업은 팀 규칙을 확인하고 진행하세요.
기본 흐름을 직접 연습하려면 Git 협업 실습 가이드를 참고하세요. 모든 회사가 같은 방식을 요구한다고 단정하지 않는 것이 정확합니다.