Git 주니어 시스템 설계 면접

main(프로덕션), develop(개발 통합), feature/기능명(개발자별 작업), release/버전명(배포 준비), hotfix/이슈명(긴급 수정) 브랜치를 운영합니다. feature는 develop에서 분기하여 작업 후 develop으로 머지하고, release는 develop에서 분기하여 QA 후 main과 develop에 모두 머지합니다. hotfix는 main에서 분기하여 수정 후 main과 develop 양쪽에 머지합니다. 모든 머지는 Pull Request를 통해 코드 리뷰 후 진행하며, main과 develop은 직접 push를 금지합니다.

멀티레포 방식을 선택하여 각 컴포넌트를 독립적인 저장소로 분리합니다. API 서버, 프론트엔드, 모바일 앱은 각각 독립적인 배포 주기를 가지므로 별도 저장소로 관리하고, 공통 라이브러리는 npm/maven 패키지로 배포하여 버전 관리합니다. 각 저장소는 독립적인 CI/CD 파이프라인을 가지며, 공통 라이브러리 업데이트 시 각 서비스에서 의존성 버전을 명시적으로 업그레이드합니다. 저장소 간 코드 공유가 필요한 경우 Git submodule이나 패키지 매니저를 활용합니다.

Conventional Commits 규칙을 사용하여 커밋 메시지를 feat(기능 추가), fix(버그 수정), docs(문서), chore(기타) 등으로 분류합니다. Semantic Versioning(MAJOR.MINOR.PATCH)을 적용하여 feat는 MINOR 버전을, fix는 PATCH 버전을 올립니다. main 브랜치에 머지될 때 GitHub Actions나 GitLab CI를 통해 커밋 메시지를 파싱하고, 자동으로 버전 태그를 생성하며, 해당 버전의 모든 커밋을 분류하여 CHANGELOG.md 파일을 업데이트합니다. 릴리즈 노트는 GitHub Release 기능을 통해 자동으로 발행합니다.

외부 기여자는 fork를 통해 자신의 저장소에서 작업하고 Pull Request를 생성하도록 합니다. PR이 생성되면 자동으로 CI가 실행되어 코드 스타일 검사(linter), 테스트, 빌드를 수행하고 결과를 PR에 표시합니다. 메인테이너만 머지 권한을 가지며, 최소 1명 이상의 코드 리뷰 승인이 필요하도록 설정합니다. PR 템플릿을 제공하여 기여자가 변경 내용, 테스트 결과, 관련 이슈를 명확히 작성하도록 하고, CONTRIBUTING.md 문서로 기여 가이드를 제공합니다. 승인된 PR은 squash merge로 커밋 히스토리를 정리하여 main 브랜치에 머지합니다.

주 저장소(GitHub)와 미러 저장소(GitLab, Bitbucket 등) 2곳 이상에 동기화하여 다중화합니다. 매일 자동으로 bare clone을 생성하여 별도 스토리지(S3, NAS)에 보관하고, 최소 30일간의 백업 이력을 유지합니다. 중요 브랜치(main, develop)는 force push를 금지하고, 삭제된 브랜치도 30일간 보관하는 정책을 설정합니다. 재해 발생 시 미러 저장소나 백업에서 복구하며, git reflog와 git fsck를 활용하여 삭제된 커밋을 복구합니다. 복구 절차를 문서화하고 분기별로 복구 훈련을 실시합니다.