【第7回】最初の実案件をGitHubから取得して開発の基準点を作る

最初の実案件を選ぶ

Ubuntuへ移行する最初の実案件には、「Studio317 Report Drafts for Google Analytics」を選びました。

このプラグインは、Google Analytics 4のデータを取得し、AIを利用してアクセス解析レポートの下書きをWordPressの投稿として作成するものです。

すでにGitHubとWordPress.orgで公開しており、今後も機能改善や保守を続ける予定です。

新しく練習用のプロジェクトを作るのではなく、実際に開発を続けているプロジェクトを移行することで、Ubuntu環境が日常業務で利用できるかを確認できます。

一方、公開中のプラグインであるため、誤った変更をGitHubへ送信したり、動作確認によって外部サービスへ影響を与えたりしないよう、最初は状態確認だけを行います。

プロジェクトを保存する場所

Ubuntu上の開発プロジェクトは、データ保存用ストレージにまとめる方針としました。

プロジェクト用の基準ディレクトリは、次の場所です。

/mnt/studio317-data/development/projects

今回のプロジェクトは、その中へ次の名前で配置します。

/mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics

前回作成したDocker環境は、次の場所で管理しています。

/mnt/studio317-data/development/docker

ソースコードを管理するプロジェクトと、WordPressやMariaDBを実行するDocker環境を分けることで、それぞれの目的が明確になります。

プロジェクトのソースコードと実行環境を分離しておけば、WordPress環境を再作成しても、Gitリポジトリへ影響を与えずに済みます。

GitHubからリポジトリを取得する

最初に、プロジェクトを保存するディレクトリへ移動します。

cd /mnt/studio317-data/development/projects

続いて、GitHubからSSH形式のURLを使用してリポジトリを取得します。

git clone \
git@github.com:studio317/analytics-report-ai.git \
studio317-report-drafts-google-analytics

git cloneは、GitHub上のリポジトリと変更履歴をUbuntuへ複製するコマンドです。

最後に指定しているstudio317-report-drafts-google-analyticsは、Ubuntu上に作成するディレクトリ名です。

取得後、プロジェクトのディレクトリへ移動します。

cd /mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics

GitHubとのSSH接続は前回までに確認しているため、パスワードをコマンドへ直接入力することなくリポジトリを取得できました。

公開名とGitHubリポジトリ名が異なる理由

今回のプラグインの公開名は、「Studio317 Report Drafts for Google Analytics」です。

WordPress.orgで使用しているスラッグと、Ubuntu上のプロジェクトディレクトリ名は、次の表記です。

studio317-report-drafts-google-analytics

一方、GitHubのリポジトリ名には、開発初期の名称であるanalytics-report-aiが残っています。

git@github.com:studio317/analytics-report-ai.git

GitHubのリポジトリ名と、現在のプラグイン名が異なっていても、Gitの動作には問題ありません。

GitHub側のリポジトリ名を変更すると、既存の開発環境、ドキュメント、参照URL、外部連携などへ影響する可能性があります。

今回は、公開上のプラグイン名とスラッグは現在の名称を使用し、GitHubリポジトリはこれまでの開発履歴を維持するため、既存の名前を継続します。

リポジトリの接続先を確認する

リポジトリを取得した後は、GitHubのどのリポジトリへ接続されているかを確認します。

git remote -v

今回の確認結果は、次のとおりです。

origin  git@github.com:studio317/analytics-report-ai.git (fetch)
origin  git@github.com:studio317/analytics-report-ai.git (push)

fetchはGitHubから変更を取得する接続先、pushはUbuntuから変更を送信する接続先です。

どちらも、予定していたstudio317/analytics-report-aiを参照していることを確認しました。

リポジトリ名が似ているプロジェクトを複数扱っている場合、誤った接続先へ変更を送信する可能性があります。

そのため、新しい環境で作業を開始する際は、ディレクトリ名だけで判断せず、git remote -vで接続先まで確認します。

現在のブランチと作業ツリーを確認する

続いて、現在のブランチと、まだGitへ記録されていない変更が存在するかを確認しました。

git status --short --branch

確認結果は、次のとおりです。

## main...origin/main

mainは、現在Ubuntuで開いているブランチです。

origin/mainは、GitHub上のmainブランチを表します。

変更されたファイルや新規ファイルが表示されていないため、作業ツリーはクリーンな状態です。

また、Ubuntu側とGitHub側のブランチに、未取得または未送信のコミットがないことも確認できました。

最新のコミットを確認する

リポジトリに記録されている最新のコミットも確認します。

git log -1 --oneline --decorate

今回の確認結果は、次のとおりです。

074b091 (HEAD -> main, origin/main, origin/HEAD) 0.2.0

074b091は、最新コミットを識別するための短縮されたハッシュ値です。

HEAD -> mainは、現在開いている位置がUbuntu側のmainブランチであることを示します。

origin/mainとorigin/HEADも同じコミットを指しているため、Ubuntu側とGitHub側が同じ状態であることを確認できました。

コミットメッセージは0.2.0で、現在の公開開発版に対応する基準点です。

確認コマンドをまとめて実行する

今後も、新しく取得したプロジェクトや、しばらく作業していなかったリポジトリでは、同じような確認を行います。

今回は、次のコマンドをまとめて実行しました。

printf '%s\n' '--- repository root ---'
pwd

printf '%s\n' '--- remote ---'
git remote -v

printf '%s\n' '--- branch and status ---'
git status --short --branch

printf '%s\n' '--- latest commit ---'
git log -1 --oneline --decorate

確認結果は、次のようになりました。

--- repository root ---
/mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics

--- remote ---
origin  [git@github.com](mailto:git@github.com):studio317/analytics-report-ai.git (fetch)
origin  [git@github.com](mailto:git@github.com):studio317/analytics-report-ai.git (push)

--- branch and status ---

## main...origin/main

--- latest commit ---
074b091 (HEAD -> main, origin/main, origin/HEAD) 0.2.0

プロジェクトの場所、GitHubの接続先、ブランチ、作業ツリー、最新コミットを一度に確認できます。

ChatGPTやCodexへ現在の状態を共有する場合にも、この結果が基本情報として役立ちます。

プラグイン本体の情報を確認する

Gitの状態だけでなく、取得したソースコードが予定していたWordPressプラグインであることも確認します。

WordPressプラグインでは、メインのPHPファイルにプラグイン名、バージョン、必要なWordPressやPHPのバージョンなどが記載されています。

今回取得したソースコードでは、次の内容を確認しました。

Gitの最新コミットと、プラグイン本体に記載されたバージョンが、どちらも0.2.0で一致しています。

これにより、Ubuntuへ取得したリポジトリが、現在作業対象としているバージョンであることを確認できました。

すぐにファイルを変更しない

リポジトリを取得すると、Visual Studio CodeやCodexですぐにコードを開いて変更したくなります。

しかし、新しい環境へ移した直後は、最初に基準となる状態を確認することが重要です。

確認前にファイルを変更すると、取得時点から存在していた問題なのか、今回の操作によって発生した問題なのか判断しにくくなります。

今回は、次の項目が確認できるまで、ソースコードを変更しませんでした。

• 予定したディレクトリへ配置されていること
• 正しいGitHubリポジトリへ接続されていること
• mainブランチを開いていること
• GitHub側と同じコミットを参照していること
• 未コミットの変更がないこと
• プラグイン名とバージョンが予定どおりであること

ここまでを確認した時点を、Ubuntuでの開発を開始する基準点とします。

Visual Studio Codeでプロジェクトを開く

基準状態を確認した後、プロジェクトをVisual Studio Codeで開きます。

cd /mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics
code .

Visual Studio Codeのエクスプローラーには、GitHubから取得したプロジェクトのファイルとディレクトリが表示されます。

初めて開くディレクトリでは、Visual Studio Codeから、このフォルダーの作成者を信頼するか確認されることがあります。

今回は、自分で管理しているGitHubリポジトリを正しい接続先から取得したことを確認しているため、内容を確認したうえでワークスペースを開きます。

Visual Studio Code上でも、ソース管理画面に未保存の変更が表示されていないことを確認しました。

ターミナルとVisual Studio Codeの両方で同じ状態を確認することで、別のディレクトリやリポジトリを誤って開いていないことを確かめられます。

Codexをプロジェクトのルートから利用する

Codexへプロジェクトの調査や変更を依頼する場合は、対象となるリポジトリのルートディレクトリから利用します。

cd /mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics
codex

Visual Studio CodeのCodexを使用する場合も、同じプロジェクトフォルダーを開いた状態で依頼します。

最初の依頼では、すぐに機能追加や修正を行わせるのではなく、現在のプロジェクトを把握してもらいます。

このリポジトリは、WordPressプラグイン
「Studio317 Report Drafts for Google Analytics」です。

まずはファイルを変更せず、プロジェクトの構成、
現在のGit状態、プラグインのバージョン、
主な機能と依存関係を確認してください。

コミット、push、外部APIへの接続、
WordPressやデータベースの操作は行わないでください。

Codexが作業対象と現在の状態を理解してから、具体的な調査や変更を依頼します。

新しい環境で最初から大きな変更を依頼せず、認識しているプロジェクトと作業範囲を確認することが重要です。

秘密情報が含まれていないことを確認する

GitHubから取得したリポジトリには、原則としてソースコードと公開可能な設定だけが含まれている必要があります。

しかし、開発を開始する前に、秘密情報や環境固有のファイルが誤って含まれていないことも確認します。

特に注意する情報は、次のとおりです。

• Google OAuthのクライアントシークレット
• Googleのアクセストークンと更新トークン
• APIキー
• WordPressの認証情報
• データベース接続情報
• SSHの秘密鍵
• ローカル環境専用の設定ファイル

Gitで管理しないファイルは、必要に応じて.gitignoreへ記載します。

また、CodexやChatGPTへファイルやGit差分を共有する場合も、秘密情報が含まれていないことを確認してから共有します。

プロジェクトとWordPress環境を分ける

今回取得したGitリポジトリは、プロジェクト用ストレージで管理しています。

/mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics

一方、日常のWordPress開発サイトにあるプラグインディレクトリは、次の場所です。

/var/www/studio317/wordpress-dev/public/wp-content/plugins

Gitリポジトリを直接プラグインディレクトリへ複製する方法もありますが、今回はソースコードの管理場所とWordPressの実行環境を分けています。

同じソースコードを二か所へコピーすると、どちらが最新なのか分からなくなり、片方だけを変更する可能性があります。

そのため、今後はシンボリックリンクなどを利用し、一つのGitリポジトリをWordPressの開発サイトから参照する方法を検討します。

ソースコードの正本を一つに保つことで、Visual Studio Code、Codex、Git、WordPressが同じファイルを利用できる構成にします。

WindowsとWSLからの移行で変わること

これまでの開発では、WindowsとWSLを組み合わせ、Visual Studio CodeとCodexからプロジェクトを扱っていました。

Ubuntuでは、Gitリポジトリ、Visual Studio Code、Codex、PHP、Apache、MariaDBが、同じLinux環境上で動作します。

これにより、Windows側とWSL側のどちらにファイルがあるのか、どちらのPHPやGitを使用しているのかを意識する場面が減ります。

Ubuntuへ移行したことで、開発環境と実行環境の差が小さくなり、Linux上で発生する権限やパスの問題を早い段階で確認できるようになります。

今回の到達点

今回は、最初の実案件として「Studio317 Report Drafts for Google Analytics」のGitHubリポジトリを、Ubuntuのプロジェクト用ストレージへ取得しました。

リポジトリの保存場所、GitHubの接続先、mainブランチ、作業ツリー、最新コミットを確認し、Ubuntu側とGitHub側が同じ状態であることを確認しました。

最新コミットは074b091、プラグインのバージョンは0.2.0です。

Visual Studio CodeとCodexからプロジェクトを開く準備も整い、今後の変更を開始するためのクリーンな基準点を作ることができました。

実案件を新しい環境へ移す際は、すぐにコードを変更するのではなく、どのリポジトリの、どのブランチの、どのコミットを基準にするのかを確認することが重要です。