From 4bbe8766d57b8dcc3f394424307a5f52d1762c10 Mon Sep 17 00:00:00 2001 From: LESANF Date: Mon, 21 Sep 2026 22:11:54 +0900 Subject: [PATCH] revert: restore feature pull requests into the version branch The change assumed profile achievements only count pull requests merged into the default branch. That was wrong: Pair Extraordinaire x2 was unlocked by create-lesa-app#10, a feature PR merged into 0.0.3. Feature PRs into the version branch count, so the original flow stands and the CI guard that failed them is removed. docs/config.md records this so the flow is not changed for that reason again. Co-Authored-By: Claude Fable 5.1 --- .github/workflows/ci.yml | 11 ++--------- AGENTS.md | 12 ++++-------- CHANGELOG.md | 7 ------- docs/config.md | 34 +++++++++++++--------------------- 4 files changed, 19 insertions(+), 45 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 8c68251..9736bdf 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -1,12 +1,11 @@ -# PR 과 버전 브랜치 푸시에서 `check-all` 을 돌린다. 네이티브 빌드는 하지 않는다 — 러너 시간이 크고 +# PR 에서 `check-all` 을 돌린다. 네이티브 빌드는 하지 않는다 — 러너 시간이 크고 # prebuild 산출물은 커밋되지 않으므로 lint·타입·테스트까지가 여기서 얻을 수 있는 것이다. name: CI -# 버전 브랜치(0.0.9)는 PR 없이 머지되므로 푸시에서 돈다 — docs/config.md "브랜치 모델". on: pull_request: push: - branches: [master, '[0-9]+.[0-9]+.[0-9]+'] + branches: [master] # 같은 브랜치에 새 푸시가 오면 이전 실행을 버린다. concurrency: @@ -17,12 +16,6 @@ jobs: check: runs-on: ubuntu-latest steps: - - name: PR base must be master - if: github.event_name == 'pull_request' && github.base_ref != 'master' - run: | - echo "::error::PR 은 master 로만 연다. 버전 브랜치에는 로컬 머지로 넣는다 — docs/config.md '브랜치 모델'" - exit 1 - - uses: actions/checkout@v4 # 메이저만 준다 — 12.x 최신. package.json engines.pnpm 과 같이 올린다. diff --git a/AGENTS.md b/AGENTS.md index fca7158..c4dcdf9 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -195,8 +195,8 @@ OS Linking · 푸시 탭 · 인앱 · 어트리뷰션 SDK — 진입이 어디 메커니즘이라 살리고, 테이블·문구·엔드포인트만 비운다. - **검증은 사용자 몫이다.** 시뮬레이터·실기 조작은 하지 않는다. 코드 검증·구조 확인· 의존성 점검·빌드까지가 내 범위다. 그 다음은 사용자가 본다. -- **릴리즈는 모아서 낸다.** 오타·주석·코드 정리로는 버전을 올리지 않는다 — 태그 없이 - `master` 까지만 보내고 받는 쪽이 달라지는 변경(SDK 대응·버그·계약 변경)이 생겼을 때 같이 낸다. +- **릴리즈는 모아서 낸다.** 오타·주석·코드 정리로는 버전을 올리지 않는다 — 버전 브랜치에 + 쌓아두고 받는 쪽이 달라지는 변경(SDK 대응·버그·계약 변경)이 생겼을 때 같이 낸다. 릴리즈 한 번에 사용자가 `npm publish` 와 OTP 를 친다. - **릴리즈 뒤에는 `pnpm release:check` 를 돌린다.** 템플릿 태그·CLI `TEMPLATE_REF`·CLI 태그·npm 네 군데를 같이 올려야 하고, 하나만 빠지면 `npx create-lesa-app` 이 옛 템플릿을 @@ -211,12 +211,8 @@ OS Linking · 푸시 탭 · 인앱 · 어트리뷰션 SDK — 진입이 어디 - **생성·변환은 결정적으로.** 값을 손으로 옮겨 적지 않는다. 스크립트·도구·파일 복사로 한다. - **커밋 메시지는 바뀐 것과 그 이유만.** 작업 과정("앞선 조사가 빠뜨렸다" 같은)은 쓰지 않는다. Conventional Commits, 공개 레포라 영어로 쓴다. -- **`master` 에 직접 푸시하지 않고, PR 은 `master` 로만 연다.** `feature/xxx` → 로컬 머지 - (`git merge --no-ff`, PR 없음) → 버전 브랜치(`0.0.2`) → PR → `master`. 버전 브랜치로 가는 - PR 은 만들지 않는다 — GitHub 은 커밋을 처음 실어 온 PR 에 묶어서, 그 뒤의 `master` PR 에는 - 머지 커밋만 남는다(CI 가 막는다). 작업 단위가 끝날 때마다 `master` PR 을 연다. - **릴리즈는 master 머지가 아니라 태그다** — CLI 가 태그로 받으므로 master 가 앞서 있어도 - 사용자에게 가지 않는다. 태그는 master 에서 단다. +- **`master` 에 직접 푸시하지 않는다.** `feature/xxx` → PR → 버전 브랜치(`0.0.2`) → + PR → `master`. **master 로 머지되는 것이 실 배포**이고, 태그는 그 뒤에 master 에서 단다. 버전 브랜치는 릴리즈 후에도 **남긴다**(그 버전 패치용). `feature/*` 는 머지되면 지운다. 머지는 항상 **merge commit**(`gh pr merge --merge`) — squash 는 커밋 단위 이력과 `Co-Authored-By` 트레일러를 하나로 뭉갠다. 브랜치 이름에는 태그(`v0.0.2`)와 겹치지 diff --git a/CHANGELOG.md b/CHANGELOG.md index 806eed5..60ade08 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -9,13 +9,6 @@ ## [Unreleased] -### Changed - -- **PR 은 `master` 로만 연다.** 피쳐는 버전 브랜치에 로컬 머지로 넣고, 릴리즈는 master 머지가 아니라 - 태그다. GitHub 이 커밋을 처음 실어 온 PR 에 묶어서 버전 브랜치 PR 을 거친 커밋은 `master` PR 의 - 집계에서 빠졌다. CI 가 버전 브랜치 푸시에서 돌고, `master` 가 아닌 PR 은 실패시킨다 - (docs/config.md "브랜치 모델") - ## [0.0.9] — 2026-09-17 ### Added diff --git a/docs/config.md b/docs/config.md index eaec043..3942be0 100644 --- a/docs/config.md +++ b/docs/config.md @@ -348,7 +348,7 @@ breaking change 를 minor 로 낸다(semver 가 `0.x` 에 허용하는 것이다 | 구조·계약 변경(폴더 이동 · `env-candidates` 필드 · 배럴 export) | 코드 정리·내부 리팩터 | | 생성 결과가 바뀌는 것 | 문서 문장 다듬기 | -오른쪽 것들은 **태그 없이 `master` 까지만 보내고 다음 실질 릴리즈에 같이 나간다.** 릴리즈 한 번에 +오른쪽 것들은 **버전 브랜치에 쌓아두고 다음 실질 릴리즈에 같이 나간다.** 릴리즈 한 번에 `npm publish` 와 OTP 가 따라오므로 오타 수정으로 그 손이 가면 안 되고, 릴리즈 노트도 의미 없는 항목으로 희석된다. @@ -365,25 +365,20 @@ breaking change 를 minor 로 낸다(semver 가 `0.x` 에 허용하는 것이다 ### 브랜치 모델 -**릴리즈는 태그다.** CLI 가 템플릿을 태그로 고정해 받으므로(`TEMPLATE_REF`) `master` 가 -태그보다 앞서 있어도 사용자에게 가지 않는다. 버전 브랜치가 develop 역할을 한다 — 피쳐를 -거기에 모으고, 작업 단위가 끝날 때마다 `master` 로 PR 을 연다. +`master` 가 **실 배포**다. 버전 브랜치가 develop 역할을 한다 — 피쳐를 거기에 모으고, +그 브랜치를 `master` 로 머지하는 순간이 릴리즈다. ``` -feature/xxx ──로컬 머지──▶ 0.0.2 ──PR──▶ master ──tag──▶ v0.0.2 +feature/xxx ──PR──▶ 0.0.2 ──PR──▶ master ──tag──▶ v0.0.2 ``` -**PR 은 `master` 로만 연다.** 버전 브랜치로 가는 PR 은 만들지 않는다. GitHub 은 커밋을 -**처음 실어 온 PR** 에 묶는다 — 피쳐를 버전 브랜치 PR 로 넣으면 그 커밋은 거기 소속이 되고, -뒤따르는 `master` PR 에는 머지 커밋만 새로 실린다. 기본 브랜치로 머지된 PR 만 세는 집계 -(프로필 achievements 의 공동 작성 커밋 등)에서 전부 빠진다 — 2026-09 에 76개가 그렇게 빠졌다. -CI 의 `PR base must be master` 단계가 이걸 막는다. - -PR 이 없는 구간의 검증은 CI 가 버전 브랜치 푸시에서 돈다(`.github/workflows/ci.yml`). - 머지는 항상 **merge commit**(`gh pr merge --merge`)이다. squash 는 커밋 단위 이력과 `Co-Authored-By` 트레일러를 하나로 뭉갠다. +이 흐름을 프로필 achievements 집계 때문에 바꾸지 않는다. 피쳐 PR 은 버전 브랜치로 머지돼도 +센다 — Pair Extraordinaire x2 가 `create-lesa-app#10`(`ci/check` → `0.0.3`)으로 열렸다. +반영은 며칠 늦는다. 2026-09-21 에 "기본 브랜치 PR 만 센다" 고 오판해 흐름을 바꿨다가 되돌렸다. + 브랜치 이름에는 `v` 를 붙이지 않는다. 태그가 `v0.0.2` 라서 브랜치도 같은 이름이면 `git checkout 0.0.2` 가 "refname is ambiguous" 로 갈린다. @@ -393,18 +388,15 @@ PR 이 없는 구간의 검증은 CI 가 버전 브랜치 푸시에서 돈다(`. 쪽이 0.0.3 으로 못 올라오는 상황 — 그 브랜치에서 바로 작업한다. React 의 `18.x`, Node 의 `v20.x` 와 같은 유지 브랜치다. -`feature/*` 는 반대다. 머지되면 지운다(`git branch -d`) — 수명이 작업 하나짜리라 남기면 -죽은 브랜치만 쌓인다. 로컬 머지라 원격에 올릴 일도 없다. +`feature/*` 는 반대다. 머지되면 지운다(`gh pr merge --merge --delete-branch`) — 수명이 +PR 하나짜리라 남기면 죽은 브랜치만 쌓인다. ### 절차 ```bash -# 1. 피쳐는 버전 브랜치로 모은다 — PR 없이 로컬 머지. 푸시하면 CI 가 돈다 +# 1. 피쳐는 버전 브랜치로 모은다 git switch -c feature/xxx 0.0.2 -git switch 0.0.2 && git merge --no-ff feature/xxx && git push && git branch -d feature/xxx - -# 1-1. 작업 단위가 끝나면 master 로 PR — 릴리즈가 아니어도 연다(태그를 안 달면 배포가 아니다) -gh pr create --base master --head 0.0.2 && gh pr merge --merge +gh pr create --base 0.0.2 && gh pr merge --merge --delete-branch # 2. 릴리즈할 준비가 되면 — 버전 브랜치의 마지막 커밋에서 # CHANGELOG 의 [Unreleased] 를 새 버전 절로 바꾸고(Added·Changed·Fixed·Docs) @@ -412,7 +404,7 @@ pnpm version 0.0.2 --no-git-tag-version # package.json 만 바꾼다 pnpm check-all git commit -am "chore(release): 0.0.2" && git push -# 3. 릴리즈 커밋을 master 로 +# 3. 버전 브랜치를 master 로 — 이게 배포다 gh pr create --base master --head 0.0.2 --title "release: 0.0.2" gh pr merge --merge # 버전 브랜치는 지우지 않는다(아래 "버전 브랜치를 남긴다")