fix: Jekyll設定のメタデータを更新

- site.title と site.description を追加
- SEO最適化のためのメタタグを強化
- ページの可読性向上を図るための設定調整

MEMO.md

@@ -0,0 +1,173 @@
+越後さんの活用方法
+
+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. レビュー＆テスト・マージ