브랜치 운영
develop 을 통합 브랜치로 두고 기능 브랜치에서 작업해 develop 으로 PR 하는 흐름.
기본 구조
| 브랜치 | 역할 |
|---|---|
develop | 통합·머지 대상. 기능 브랜치는 여기서 분기하고 여기로 돌아온다 |
main | 명시적으로 지시가 있을 때만 머지한다 |
feat/…, fix/… | 이슈 단위 작업 브랜치 |
왜 — 기본 머지 대상을 하나로 고정해야 "어디에 합쳐야 하나"를 매번 묻지 않고, 실수로 운영 기준 브랜치에 들어가는 일을 막을 수 있습니다.
작업 흐름
# 1. 최신 develop 받기
git checkout develop
git pull <팀 저장소 remote> develop
# 2. 기능 브랜치 만들기 (이슈 단위)
git checkout -b feat/clean-reject-alert
# 3. 커밋 (명시 경로만 스테이징)
git add src/pages/cleanConfig/RejectBanner.jsx
git commit -m "[feat]: 세척설정 로봇 거부 알림 - 거부 항목 배너 추가 (#120)"
# 4. 푸시
git push -u <remote> HEAD
# 5. PR — base 는 develop
gh pr create --base develop
- PR 기준(base)은
develop입니다.main으로 PR·머지하지 않습니다(명시 지시가 있을 때만). - 큰 기능은 별도 기능 브랜치·별도 릴리스로 분리합니다.
원격 저장소(remote) 규칙
한 저장소에 여러 원격이 연결돼 있을 수 있습니다(개인 포크, 팀 저장소 등).
- 각 저장소 규약에 허용된 원격과 사용 금지 원격이 적혀 있으면 그대로 따릅니다.
- 사용 금지로 지정된 원격에는 fetch·push·PR 을 하지 않습니다.
- 원격 URL 에 토큰을 넣지 않습니다 ('보안 기본 규칙' 문서 참조).
다른 팀 저장소에서는
다른 팀이 소유한 저장소(예: 로봇 소프트웨어 저장소)에서는 그 팀의 규칙이 우선합니다. 병합 권한이 소유 팀에만 있으면 커밋·푸시까지만 하고 병합은 소유 팀에 맡깁니다.