AIで作ったアプリでGitを使う方法

AIで作ったアプリでGitを使うには、プロジェクトをGitリポジトリに接続し、動作する変更ごとにコミットし、何が変わったかを1行のメッセージで書き、.gitignoreで秘密情報を除外します。危険な作業にはブランチを使い、他の人がコードを変更していたら次の指示を出す前にpullします。AIが何かを壊したら、混乱した状態の上にさらに指示を重ねるのではなく、最後に正常に動いていたコミットに戻します。

Gitはバージョン管理システムで、コードの保存されたすべてのバージョンの履歴を残します。GitHubは、Gitリポジトリをオンラインで保存するWebサイトです。これらが初めてなら、まずGitHubとはをご覧ください。このガイドでは、AIがほとんどのコードを書く場合に、Gitを役立てるための習慣を扱います。

AIで開発するとGitがより重要になる理由

AIは1回のターンで20個のファイルを変更することがあります。速い反面、1回の指示で、昨日テストした部分が静かに壊れることもあります。Gitは次のものを提供します。

• 元に戻す方法。 コミットされた任意のバージョンに戻せます。
• 変更の記録。 1回の指示がどのファイルのどの行に触れたかを正確に確認できます。
• ビルダーの外側のコピー。 コードは自分で管理できる場所に残ります。
• 標準的な引き継ぎ。 どの開発者、ホスティングサービス、ツールも、Gitリポジトリから作業できます。

ステップ1：リポジトリを接続する

GitHubや類似のサービスで（通常はプライベートな）リポジトリを作成し、プロジェクトを接続します。Gitに対応しているほとんどのAIアプリビルダーは、設定ページの「Connect GitHub」ボタンからこれを行います。対応していない場合は、コードをエクスポートして自分でpushするか、一度だけ開発者に設定を頼んでください。

最初のpushの前に、リポジトリに含めるべきでないものを無視するように設定してください。

.gitignoreファイルを確認してください。.envファイル、node_modules、ビルド出力のフォルダ、秘密情報を含むファイルが除外されていることを確認し、追加した内容を教えてください。

ステップ2：動作する変更ごとにコミットする

コミットは、メッセージを付けて保存したスナップショットです。重要な習慣は次のとおりです。何かが動いたら、次の作業を頼む前にコミットする。

1. 1つの変更を指示する。
2. プレビューで確認する。
3. 動作したら、メッセージを付けてコミット（または同期）する。
4. 次に進む。

小さなコミットにしておけば、何かが壊れたときにどの変更が原因か分かり、その1つを取り消しても他の作業は失われません。

ステップ3：後で読めるメッセージを書く

良いメッセージは、何が変わったかを1行で示します。

• 良い例：注文ページにCSVエクスポートを追加
• 良い例：18時以降の時間を予約フォームが拒否する問題を修正
• 役に立たない例：update、changes、fix stuff

AIに書いてもらうこともできます。

前回のコミット以降の変更を、動詞で始めて70文字以内の1行にまとめてください。

ステップ4：危険な作業にはブランチを使う

ブランチは、独立した作業の流れです。ブランチで試して、うまくいかなければ、メインのバージョンに触れずに捨てられます。

次のような場合にブランチを使います。

• 変更が大きい（デザインの刷新、新しい支払いフロー、データベースの変更など）。
• 同じアプリを他の人も作業している。
• 公開前に、誰かに変更をレビューしてもらいたい。

作業が終わってテストが済んだら、そのブランチはメインのブランチにマージされます。GitHubでは通常、変更をレビューするためのページであるプルリクエストを通して行われます。ビルダーが1つのブランチだけを同期する場合は、GitHub側のブランチ管理を開発者に任せられます。

ステップ5：安全に元に戻す

指示でアプリが壊れたときは、その上にさらに5回指示を重ねたくなるかもしれませんが、我慢してください。最後に正常だったバージョンに戻し、より明確な指示で試し直しましょう。

• ビルダーの場合： チェックポイントや復元の機能があれば、それを使います。
• Gitの場合： git revertは、古いコミットを取り消す新しいコミットを作るので、履歴をそのまま保てます。他の人がpullしたかもしれないコードには、この方法が安全です。
• 共有ブランチではgit push --forceを避けてください。 履歴が全員分書き換わるので、理由がはっきりしている場合を除いて使わないでください。

判断に迷ったら、次のように尋ねてください。

直前の変更でログインページが壊れました。前のコミットと比べて、どのファイルが変わったかを示し、それぞれの変更が何をしたかを説明してください。まだ何も変更しないでください。

ステップ6：指示の前にpullする

開発者や別のツールがGitHub上のコードを変更しても、その変更をpullして取り込むまで、AIビルダーはそれを知りません。古いコードに対して指示を出すと、競合や作業の消失が起きます。

• セッションを始めるたびに、pullしてください。
• 誰が何を編集するかを決め、両方が同時に同じファイルを編集しないようにします。
• マージコンフリクト（同じ行への2つの変更）が起きたら、開発者かAIに解決を頼み、その選択の理由を説明してもらいましょう。

指示の例

始める前に：前回のセッション以降、リポジトリで何が変わったかを、コミットごとに要約してください。

次の変更は単独で行ってください。各請求書に「複製」ボタンを追加します。それ以外は何も変更せず、別々にコミットできるようにしてください。

APIキー、パスワード、.envファイルが、過去のコミットを含めてGitで追跡されていないか確認してください。ファイル名だけを報告し、値は表示しないでください。

よくある間違い

• 秘密情報のコミット。 一度Gitの履歴に入ったキーは、ファイルを削除しても露出したままです。キーを無効化してください。
• 1週間に1つの巨大なコミット。 1つの変更だけを取り消すことができず、すべてを取り消すことになります。
• 「update」のようなメッセージ。 何が壊れたかを探すのに、履歴が役に立たなくなります。
• 古いコードへの指示。 他の人が編集しているときは、先にpullしてください。
• ミスを直すための強制push。 他の人の作業を消してしまうおそれがあります。代わりにrevertしてください。
• node_modulesのコミット。 非常に大きく、どのみちロックファイルから再作成されます。

チェックリスト

• プロジェクトがプライベートリポジトリに接続されている。
• .gitignoreで.env、node_modules、ビルド出力、秘密情報を除外している。
• 動作する変更ごとにコミットしている。
• コミットメッセージが、変更内容を1行で示している。
• 大きい、または危険な変更はブランチで作業し、レビューを受けている。
• 他の人がコードを編集している場合は、指示の前にpullしている。
• チェックポイントかgit revertで元に戻していて、強制pushはしていない。
• 一度でもコミットされたキーは無効化して再発行した。

MythexでのGit

Mythexは、AIエージェントのターンが成功するたびにGitのチェックポイントを保存し、この時点に戻すを押すと、プロジェクトをそのチェックポイントに戻せます。これはステップ5で説明した、ビルダー側の取り消しです。詳しくは反復作業をやり直さずに進めるをご覧ください。

Proプランでは、プロジェクト設定からGitHub同期でリポジトリを接続し、pushやpullができます。エクスポートでは、秘密情報とnode_modulesを除いたプロジェクトをダウンロードできます。詳しくはGitHub、エクスポート、インポートをご覧ください。プロジェクトを開発者に渡す前にGitHubを接続しておくと、引き継ぎがずっと簡単になります。AIで作ったアプリで開発者と協働する方法と、AIで作ったアプリをエクスポートしてセルフホストする方法もご覧ください。

よくある質問