ReplitとGitHubを連携して変更を同期する基本

ReplitとGitHubを連携すると、Replit上の作業をGitの変更として記録し、GitHubへ共有できます。安全に同期するには、Replit AgentのCheckpointだけに頼らず、作業開始前に接続先とbranchを確認し、変更後にdiffを読み、commit・pushの順に進めます。Checkpointは復元用の作業記録、Git commitは共有する履歴です。両方の役割を分けると、AIが加えた変更も追跡できます。

先に決めるのは「どちらを正本にするか」

連携の前に、ReplitとGitHubのどちらを正本にするかを決めます。すでにGitHubで開発していて、ローカルPCやCIも同じrepositoryを使うなら、GitHubのdefault branchを共有の基準にするのが分かりやすいでしょう。Replitは編集・実行環境として使い、完成した変更をGitHubへ戻します。

逆に、Replitだけで作り、他の開発環境やチームと共有しない小さな試作なら、Replit側を中心に始めることもできます。ただし後からGitHubを接続する場合、どちらに新しいcommitがあるかを確認してから統合します。「最後に編集した場所が最新版」と思い込むと、片側の変更を上書きする危険があります。

この判断は接続ボタンより先に必要です。最初にrepositoryのURL、default branch、作業用branch、同期方向をメモし、共有相手と合意しておきます。public repositoryかprivate repositoryか、Replitへ許可する範囲も確認してください。会社や顧客のcodeを扱うなら、個人アカウントに接続してよいか、組織のGitHub Appや権限設定に従う必要があります。

初回接続は既存repoをimportする

既存projectを引き継ぐなら、新しいReplit projectを空で作ってfileを手動コピーするより、GitHub repositoryをimportする方法を優先します。import時にはGitHub accountの認証、選択したrepository、初期branchを確認します。名前が似たrepositoryが複数ある場合は、ownerとURL末尾まで見て対象を確定します。

import後は、実行前に次を確認します。

• READMEや主要directoryが想定どおりある

• default branchが意図したbranchと一致する

• package.json、依存関係、起動設定が元repoと同じ

• .env、API key、顧客データなどがGitに含まれていない

• 既存の未commit変更がある場合、その内容と所有者が分かる

importは同期の開始点であり、今後の変更を自動的に安全に統合する保証ではありません。特に、別PCで作業を続けているrepositoryなら、最初にGitHub側の最新commitとReplit側の作業treeを比べます。初回に差分が出たら、pushを急がず、どちらの変更を残すか決めてください。

日常作業はbranchから始める

小さな修正でも、共有中のdefault branchを直接編集するより、task用branchを作ると変更の境界が明確になります。例えばfix-login-copyのような名前を付け、「ログイン説明の文言を直す」以外を同じbranchへ混ぜないようにします。Agentへ依頼する場合も、変更対象と禁止範囲を指示し、作業前の状態をCheckpointやGitで保存します。

作業の最小単位は次のように考えられます。

1. Git paneでrepositoryと現在のbranchを確認する。

2. GitHubから最新変更を取り込む必要があるか調べる。

3. task branchを作成または切り替える。

4. Agentへ、目的・対象file・テスト・変更禁止範囲を伝える。

5. 変更後にdiffを読み、想定外fileや秘密情報を確認する。

6. テストが通った変更だけをcommitする。

7. remoteとの差がない状態を確認してからpushする。

8. pull requestやreviewを使う運用なら、その流れに従う。

例えば「ボタン文言だけを修正」と依頼したのに、依存fileの大量更新や環境設定の変更まで混ざっていたら、そのままcommitしません。目的外の変更が必要かを判断し、不要ならAgentへ戻して範囲を絞ります。Checkpointがある場合でも、Git diffの確認を省略しないでください。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  Replit

  公式サイトを見るTool詳細を見る

Checkpoint、File History、Git commitを使い分ける

Replitには作業を戻す仕組みが複数あります。Agent CheckpointはAgent作業の節目を復元するためのsnapshotです。File Historyは個別fileの編集履歴をたどる用途、Git commitはrepository全体の共有履歴を残す用途です。画面上にCheckpointが見えることだけで、その変更がGitHubへpush済みとは判断できません。

目安として、Agentの直前の変更を試しに戻したいときはCheckpoint、1つのfileの直前編集を見たいときはFile History、チームに共有する変更を残すときはGit commitを使います。Replitのversion control documentationでは各方式が同じGit repositoryに関係する一方、作成方法・粒度・説明・復元の扱いは異なると説明されています。Checkpointの説明文も人が書いたcommit messageの代わりにはなりません。

また、commitとpushも別の操作です。commitは現在のrepositoryに履歴を記録し、pushはその履歴をGitHubへ送ります。commitが成功してもpushが未実施なら、GitHub上のbranchには変更が届いていません。同期完了を伝えるときは、「commitした」「pushした」を区別しましょう。

変更内容はファイル名よりdiffで判断する

Git paneに表示される変更file数だけでは、変更の妥当性は分かりません。ファイルごとの差分を読み、追加・削除・変更の意図を確認します。特に次は重点確認します。

• .env、秘密鍵、token、接続文字列が追加されていない

• lockfileやdependency versionが依頼外に変わっていない

• generated fileやbuild outputが意図せず混ざっていない

• 認証、権限、データ削除、課金処理に関わる変更がない

• testや型が壊れていない

• renameや削除が必要な理由を説明できる

Agentが作った大量の差分を一度に受け入れるより、機能単位に分けて確認します。変更が大きいときは、目的に関係するfileだけを先にレビューし、依存する変更は必要性を確認してから扱います。reviewできない差分は、理解できるまでpushしません。

push / pullで困ったときの切り分け

pushが拒否されたら、まずGitHub側にReplitにないcommitが追加された可能性を確認します。remoteをpullせず、画面上のエラーだけを見てforce pushするのは避けます。相手の変更と自分の変更を比較し、mergeまたはrebaseなど、チームが定めた方法で統合します。

conflictが出た場合は、conflict markerのあるfileを確認します。片側を機械的に選ぶのではなく、両方の変更が何を解決しようとしているかを読みます。lockfileや生成物では手編集が難しい場合があるため、元の依存定義から再生成する手順を確認します。解消後は差分、test、起動結果を確認してからcommitします。

画面上で同期済みと表示されるのにGitHubに見当たらない場合は、branch名、remote repository、push状態を順に見直します。別branchへpushしていることもあります。ReplitとGitHubで同名branchが存在するだけでは、同じcommitを指すとは限りません。

AI開発で使えるhandoffメモ

Replit Agentの作業を別環境や別担当へ引き継ぐときは、Checkpointの説明だけでなく、再現に必要な情報を短く残します。

• repository URLとbranch

• 変更目的と対象file

• 実行したtestと結果

• 未解決事項、既知のfailure

• 必要なenvironment variable名（値は書かない）

• 次に行う操作

• 変更をpush済みか、commit hash

例えば「検索画面を修正。feature/search-filterへcommit済み。unit test pass。mobile layout未確認。次は390pxでQA」のように書けば、次の人は作業状態を誤解しにくくなります。認証情報はhandoff文書へ貼らず、承認されたsecret managerを使います。

AIものさしの判断

ReplitとGitHubの連携を「自動で同期する仕組み」とだけ捉えると、CheckpointとGit履歴、commitとpush、ReplitとGitHubの正本が混ざります。まず正本を決め、branchで作業し、Agentの変更をdiffとtestで確認してからcommit・pushするのが基本です。

Agentに任せる範囲は、変更のリスクに応じて変えます。説明文や試作UIなら小さなbranchで進められますが、認証、secret、顧客データ、production設定は人の確認を必須にします。連携の便利さより、変更がどこに記録され、誰がレビューし、どの環境へ届くかが分かる状態を優先してください。

次の作業は、対象repositoryをimportし、branchを確認し、意図的に小さな変更を1件だけ作って差分を読むことです。その変更をcommitするかどうかは、testとレビューが完了してから決めます。