# 브랜치 운영

## 기본 구조

| 브랜치 | 역할 |
|---|---|
| `develop` | **통합·머지 대상.** 기능 브랜치는 여기서 분기하고 여기로 돌아온다 |
| `main` | 명시적으로 지시가 있을 때만 머지한다 |
| `feat/…`, `fix/…` | 이슈 단위 작업 브랜치 |

> 왜 — 기본 머지 대상을 하나로 고정해야 "어디에 합쳐야 하나"를 매번 묻지 않고, 실수로 운영 기준 브랜치에 들어가는 일을 막을 수 있습니다.

## 작업 흐름

```bash
# 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 에 토큰을 넣지 않습니다 ('보안 기본 규칙' 문서 참조).

## 다른 팀 저장소에서는

다른 팀이 소유한 저장소(예: 로봇 소프트웨어 저장소)에서는 그 팀의 규칙이 우선합니다. 병합 권한이 소유 팀에만 있으면 **커밋·푸시까지만** 하고 병합은 소유 팀에 맡깁니다.