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. 開発完了後に〇〇する→ここがわからない
   3. テストフェーズ
      1. 概要
         1. 開発完了した後にテストを実行する
      2. 流れ
         1. ここもわからない

2. 機能追加

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

3. バグ修正

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