github-research-tool/MEMO.md

越後さんの活用方法

mainを軸にするがいじるときはすべてbranchにしてる

issueごとにbranchを切って、完了後にmainにmergeする→同時に動かしている場合はどうすればいいのかな？
ステージング環境・開発環境のbranchも構築しておく

main
↓
開発環境
↓
issueごと

ってイメージ

PRは開発環境にmergeして確認を行うとのこと


worktree
→リポジトリと同レベルの階層にworktreeのフォルダが作られるとのこと



開発の流れを考えたい
1. 新規
2. 機能追加
3. テスト

シナリオ1：新規開発（ゼロからプロジェクトを始める）
これは、新しいアイデアを形にする最初のステップです。

計画フェーズ（何をやるか決める）

Issueを作成: まず、この新規プロジェクトで達成したいことの全体像を、一つの大きなIssueとして作成します。「ユーザー管理機能を持つブログアプリを作る」などです 。   

タスクを分解: その大きなIssueの本文に、チェックリスト形式で必要な機能（「ユーザー登録」「記事投稿」「記事一覧表示」など）を書き出します。これが最初のタスクリストになります 。   

プロジェクトボードに追加: 作成したIssueをGitHub Projectsのカンバンボードに追加し、「Todo」カラムに配置します 。   

開発フェーズ（コードを書く）

リポジトリを作成: GitHub上に新しいリポジトリを作成します。

初期開発: この段階ではブランチはmain（またはdevelop）一本で進めることが多いです。まずは基本的な土台（フレームワークの導入、ディレクトリ構成の決定など）を構築します。

コミット: ある程度キリの良いところでコミットを重ねていきます。

テストフェーズ（品質を保つ仕組みを作る）

自動テストを設定: GitHub Actionsを使い、「mainブランチにコードがプッシュされたら、自動でテストを実行する」というワークフローを設定します。これにより、今後の開発で土台が壊れていないかを常にチェックできます。

シナリオ2：機能追加（最も一般的な開発サイクル）
ここからがgit worktreeの真価が発揮される場面です。

計画フェーズ

Issueを作成: 追加したい機能（例：「記事にコメントを付ける機能」）をIssueとして作成します 。バグの可能性や仕様などを詳細に記述し、   

featureラベルを付けます。

プロジェクトボードで管理: 作成したIssue（#123とします）をGitHub Projectsのカンバンボードの「Todo」カラムに配置します。

開発フェーズ

作業場を準備 (git worktree): 今、別の作業をしていたとしても問題ありません。stashは不要です。ターミナルで以下のコマンドを実行し、新しい作業場を瞬時に用意します。

Bash

# feature/comment-function という新しいブランチを作り、
#../comment-work という新しいフォルダに展開する
git worktree add -b feature/comment-function../comment-work
開発に着手: cd../comment-workで新しい作業場に移動し、コーディングに集中します。

Issueと連携: コミットメッセージにIssue番号を含めることで、進捗を自動で連携させます 。   

Bash

git commit -m "feat: コメント投稿フォームを作成 #123"
レビュー＆テストフェーズ

プルリクエストを作成: 作業が終わったら、feature/comment-functionブランチをプッシュし、GitHub上でmainブランチへの**プルリクエスト（PR）**を作成します 。PRのタイトルや本文にもIssue番号を記載すると、関連性が一目瞭然になります 。   

自動テストを実行 (GitHub Actions): PRが作成されると、GitHub Actionsが自動的に起動し、この変更によって既存の機能が壊れていないかをテストします。

コードレビュー: 他のメンバー（あるいは未来の自分）がPRを見て、コードに対するフィードバックをコメントします。

修正: 指摘があれば、comment-workフォルダで修正し、再度プッシュします。PRは自動で更新されます。

マージ＆デプロイ

マージ: レビューで承認（Approve）され、すべてのテストが通ったら、PRをマージします。これで新機能がmainブランチに統合されます。

後片付け: 不要になった作業場とブランチを片付けます。

Bash

# まずはメインの作業場に戻る
cd../my-project 
# 作業場を削除
git worktree remove../comment-work
# ブランチを削除
git branch -d feature/comment-function
シナリオ3：バグ修正（緊急の割り込み作業）
git worktreeが最も輝くシナリオの一つです。

計画フェーズ

Issueを作成: 発見されたバグ（例：「特定の条件下でコメントが投稿できない」）をIssueとして作成します。再現手順などを詳しく書き、bugラベルと高い優先度を設定します。

開発フェーズ

割り込み作業の開始 (git worktree): あなたが「機能追加」の作業に集中している真っ最中でも、今の作業を一切中断する必要はありません。

Bash

# hotfix/comment-bug という新しいブランチをmainから作り、
#../bugfix-work というフォルダに展開する
git worktree add -b hotfix/comment-bug../bugfix-work main
修正作業: cd../bugfix-workでバグ修正用の作業場に移動し、迅速に修正を行います。コミットメッセージにはfix:という接頭辞とIssue番号を入れます。

Bash

git commit -m "fix: コメント投稿時の認証エラーを修正 #124"
レビュー＆テスト、マージ

ここからの流れは「機能追加」とほぼ同じです。PRを作成し、自動テストとレビューを経て、迅速にmainブランチにマージします。

まとめ
シナリオ	計画（どこで？）	開発（どうやって？）	レビュー（どうやって？）	テスト（いつ？）
新規開発	GitHub Issueで全体像を定義	mainブランチで土台を構築	不要	mainへのプッシュ時
機能追加	GitHub Issueでタスク化	git worktreeで独立した作業場を作成	Pull Requestで議論	PR作成・更新時
バグ修正	GitHub Issueで問題を報告	git worktreeで緊急避難的に作業場を作成	Pull Requestで迅速に確認	PR作成・更新時

Google スプレッドシートにエクスポート
この3つの流れを基本の型として持っておくことで、どんな状況でも迷うことなく、ADHDの特性を活かした柔軟でスピーディーな開発を進めることができるようになります。




1. 新規開発
   1. 計画フェーズ
      1. 概要
         1. どんなものを作るのかの仕様書を作ってすべてのタスクをissueを作成する
      2. 流れ
         1. リポジトリを作る
         2. 開発用ブランチを作る
         3. 仕様書を作成する
         4. タスクを一覧化する
         5. issueに記載する 
   2. 開発フェーズ
      1. 概要
         1. 計画で決まったissueを進めていき完成させる
      2. 流れ
         1. 開発用ブランチを起点に各issue用のブランチを作る
         2. 各issue用のブランチにcheckoutして開発を進める
         3. 開発完了後に〇〇する→ここがわからない
         4. 
   3. テストフェーズ
      1. 概要
         1. 開発完了した後にテストを実行する
      2. 流れ
         1. ここもわからない

2. 機能追加
   1. 計画フェーズ
   2. 開発フェーズ
   3. レビュー＆テストフェーズ
   4. マージ＆デプロイ

3. バグ修正
   1. 計画フェーズ
   2. 開発フェーズ
   3. レビュー＆テスト・マージ


# 新規開発ワークフロー 詳細設計書（再検討版）

## 1. 計画フェーズ：思考を外部化し、道筋を立てる

### 概要
このフェーズの目的は、頭の中にある漠然としたアイデアを、誰が見ても理解できる具体的なタスク群に変換し、外部システム（GitHub）に完全に記録することです。これにより、「何をすべきか」を記憶しておく必要がなくなります。

### 流れ

1. **リポジトリの作成**: GitHub上で、この新規プロジェクトのためのリポジトリを1つ作成します。

2. **ブランチ戦略の決定**:
   - `main` ブランチ：常にリリース可能な、安定したコードを置く場所とします
   - `develop` ブランチ：これから開発する機能や修正を統合していくための、中心的な開発用ブランチとします。mainブランチからこのdevelopブランチを作成します。

3. **仕様書の作成**:
   - リポジトリの README.md ファイルに、このプロジェクトが「何を」「なぜ」「誰のために」作るのか、という核心的な目的を書き出します。これがプロジェクトの憲法となり、モチベーションの源泉になります。

4. **タスクの洗い出しと分解**:
   - 仕様書を基に、プロジェクト完成に必要なタスクをすべて洗い出します。
   - 「ユーザー認証機能」のような大きなタスクは、「ログイン画面UI作成」「APIエンドポイント設計」「DBテーブル作成」のように、数時間〜1日で完了できるレベルまで細かく分解します。これは着手のハードルを劇的に下げます。

5. **全タスクのIssue化**:
   - 分解したタスクを一つ残らず、GitHubのIssueとして作成します。
   - 各Issueには、`feature`（機能追加）、`bug`（バグ）、`chore`（雑務）などのラベルを付け、整理します。
   - 作成したIssueはすべてGitHub Projectsのカンバンボードに追加し、「Todo」カラムに配置します。

## 2. 開発フェーズ：集中と柔軟性を両立させる

### 概要
計画フェーズで作成したIssue（指示書）に基づき、一つずつタスクをこなしていきます。ここではgit worktreeを最大限に活用し、集中を妨げることなく、興味の波に合わせた柔軟なタスク切り替えを実現します。

### 流れ

1. **Issueの選択**: GitHub Projectsのカンバンボードから、今日取り組むIssueを1つ選び、「進行中」カラムに移動させます。

2. **作業場の準備 (git worktree)**:
   - ターミナルでメインの作業フォルダ（developブランチがチェックアウトされている場所）にいることを確認します。
   - 取り組むIssue（例: #11）のために、以下のコマンドで新しい作業場（フォルダ）とブランチを瞬時に作成します。
   ```bash
   # developブランチを基に、feature/11-login-ui という新しいブランチを作り、
   # ../login-ui-work という新しいフォルダに展開する
   git worktree add -b feature/11-login-ui ../login-ui-work develop
   ```

3. **開発に着手**:
   - `cd ../login-ui-work` で新しい作業場に移動し、コーディングに集中します。元の作業フォルダのことは完全に忘れて大丈夫です。

4. **コミットとプッシュ**:
   - キリの良いところで、こまめにコミットします。コミットメッセージにIssue番号（#11）を入れると、自動でIssueと関連付けられます。
   ```bash
   git commit -m "feat: ログインフォームのUIコンポーネントを作成 #11"
   ```
   - 作業が完了したら、ブランチをリモートリポジトリにプッシュします。
   ```bash
   git push origin feature/11-login-ui
   ```

5. **プルリクエストの作成**（開発完了後の具体的なアクション）:
   - GitHub上で、今プッシュしたfeature/11-login-uiブランチからdevelopブランチへの**プルリクエスト（PR）**を作成します。
   - PRは「この変更を開発用ブランチに加えても良いですか？」というレビュー依頼です。
   - PRの説明欄に `Closes #11` と書くことで、このPRがマージされた時にIssue #11 が自動でクローズされるように設定します。

## 3. レビュー＆統合フェーズ（テストフェーズ）

### 概要
作成したプルリクエスト（PR）を通じて、変更内容が安全であることを確認し、開発の中心であるdevelopブランチに統合します。ここでの主役は自動化とコミュニケーションです。

### 流れ（テストフェーズの具体的な流れ）

1. **自動テストの実行 (GitHub Actions)**:
   - PRが作成されると、それをきっかけ（トリガー）にGitHub Actionsが自動的に起動します。
   - あらかじめ設定しておいたテスト（単体テスト、結合テストなど）が実行され、この変更によって既存の機能が壊れていないかがチェックされます。
   - 結果はPRページに「✔︎ All checks have passed」のように表示され、品質を客観的に保証します。

2. **コードレビュー**:
   - 他の開発者（あるいは未来の自分）がPRの「Files changed」タブを見て、コードの変更内容を確認します。
   - 「この変数名はもっと分かりやすい方が良い」「ここのロジックはもっとシンプルに書ける」といったフィードバックを、コードの特定の行に対してコメントします。

3. **フィードバック対応と修正**:
   - レビューコメントを受けたら、自分の作業場（../login-ui-workフォルダ）でコードを修正します。
   - 修正内容をコミットし、再度プッシュします。PRは自動的に最新の状態に更新され、GitHub Actionsによるテストも再実行されます。

4. **マージ**:
   - すべての自動テストが成功し、レビューで承認（Approve）されたら、PRページの「Merge pull request」ボタンを押します。
   - これで、あなたの変更が安全にdevelopブランチに統合されます。

5. **後片付け**:
   - developブランチに統合されたので、作業用のブランチと作業場は不要になります。メインの作業フォルダに戻り、以下のコマンドでクリーンアップします。
   ```bash
   # メインの作業場に戻る
   cd ../my-project
   
   # 不要になった作業場を削除
   git worktree remove ../login-ui-work
   
   # 不要になったブランチをローカルとリモートから削除
   git branch -d feature/11-login-ui
   git push origin --delete feature/11-login-ui
   ```

この一連の流れを繰り返すことで、一つ一つのタスクを確実にこなしながら、プロジェクト全体を着実に完成へと導くことができます。

## worktreeを使った並行作業の管理

複数のIssueを同時に進める場合の具体例：
- Issue #11: ログイン機能を作っている途中
- Issue #12: 急にバグ修正が必要になった  
- Issue #13: UIの改善アイデアが浮かんだ

```bash
# 現在の作業状況
../my-project/        # developブランチ（メイン作業場）
../login-work/        # Issue #11用（feature/11-login）
../bugfix-work/       # Issue #12用（hotfix/12-auth-error）
../ui-improve-work/   # Issue #13用（feature/13-ui-improvement）

# 作業場間の移動は単純にcdするだけ
cd ../bugfix-work     # バグ修正に切り替え
cd ../login-work      # ログイン機能に戻る
```

それぞれの作業場は完全に独立しているので、コミットしていない変更があっても問題なく切り替えられます。