【Git】作業ブランチで修正をするコマンド｜working branch

作業ブランチ？

作業ブランチが必要な理由はこう

How to Proceed (Safe Refactor Flow)

Overall Concept

Perform a safe feature refactor by:

1. Tagging your current state (snapshot insurance)
2. Creating a clean feature branch (isolate from main)
3. Making small, testable commits
4. Cleaning up history before PR

This ensures traceable progress, rollback safety, and clean CI flow.

Step-by-Step Guide

Step 1: Optional but Safe — Tag the Current State

Creates a flag (“bookmark”) to safely return anytime.

現状を旗立て（タグ）しとく（任意だけど安心）

git status
git log --oneline -n 3
git tag -a pre-split-2025-10-05 -m "before timer split"

Step 2: Create a Feature Branch (Protect Main)

Work in isolation to avoid polluting the main branch.

ブランチ切る（メインは汚さない）

git switch -c feat/timer-split       # = git checkout -b ...
# If remote branch already exists:
# git push -u origin feat/timer-split

Step 3: Start Small — Scaffold Only

Create just the “shells” for new classes. No logic changes yet.

小さく器だけ置く → 通すだけコミット

# Add empty controllers/helpers with current call structure
git add -A
git commit -m "scaffold: add TimerSessionController and TimerResetAndFormat (no behavior change)"

Step 4: Delegate One Method at a Time

委譲を 1 メソッドずつ進める（小刻み）

# Example: delegate start/pause/resume to new class
git add -p
git commit -m "refactor(vm): delegate start/pause/resume to session controller"

• Verify: logs, phase transitions, background→foreground behavior
  • 毎回、通知ログ・フェーズ遷移・BG→FGを軽く手確認
• Small commits = easy rollback, clean diff
  • 小コミットを積む（壊れたらすぐ戻せる）

Step 5: Notification Policy (Enforced in Service Layer)

通知ポリシー固定（サービス側で保証）

• Start = schedule only
• Complete = immediate only
• Phase-based IDs with cancel→add enforced
• MainActor hop ensures ordering

• 開始＝予約のみ / 完了＝即時のみ
• phase別ID＋cancel→add をサービスで強制
• MainActor hop で順序保証

git commit -m "chore(notify): enforce start-only scheduling and phase-based identifiers (cancel→add)"

Step 6: Clean Up Thin Wrappers / Visibility

薄いラッパーの整理・可視性落とし

git commit -m "cleanup(api): remove thin wrappers and make unused APIs private/internal"

Step 7: Prepare for PR — Clean History (Optional)

まとまったら PR 用に履歴を綺麗にする（任意）

If you want to rework commits before PR:

ローカルだけで綺麗化したいなら インタラクティブ rebase

git fetch origin
git rebase -i origin/main   # use pick/squash/reword to tidy history

If you want to merge all locally into one commit:

一発にまとめたいなら（チーム流儀が “squash merge” なら不要）

git reset --soft origin/main
git commit -m "refactor: extract timer controllers, unify lifecycle, solidify notification policy"

Step 8: Create Pull Request & Check CI

PR 作成 & CI

git push -u origin feat/timer-split
# → Create PR on GitHub/GitLab → Review → Check CI

Rollback Tactics (If Something Breaks)｜失敗したらロールバック

Within the feature branch:

作業ブランチ内で戻す

git log --oneline
git revert <bad_commit_hash>   # create revert commit (keeps history)
# or
git reset --hard <good_commit_hash>   # destructive rollback (beware if pushed)

Redo PR Cleanly:

PR をやり直す（クリーンに差し替え）

git switch main
git pull --ff-only
git switch -c feat/timer-split-v2
git cherry-pick <good_commit_1> <good_commit_2> ...

Full Restore (using tag):

どうしても全消ししたい（タグ帰還）

git switch main
git reset --hard pre-split-2025-10-05
git push -f origin main   # team agreement required

Lint / CI Temporary Fix｜Lint/CI で詰まった時の応急

To bypass long-file warnings temporarily:

一時的にファイル長エラーを抑制して PR を通す→分割→抑制解除

// swiftlint:disable file_length type_body_length
// ... refactor here ...
// swiftlint:enable file_length type_body_length

Remove after stable split!

Final Checklist

• Feature branch created and pushed (-u included)
• Small, frequent commits (rollback-ready)
• Notifications: start = schedule only / complete = immediate
• Phase-based ID, cancel→add, MainActor hop enforced
• Resume does not force work start (only Start does)
• Lifecycle through Coordinator (idempotent)
• History cleaned with rebase -i or squash before PR
• Smoke test scenarios passed