Posts

冒頭まとめ git pullで次のエラーが出た場合、取得した履歴を現在のブランチへどう取り込むかが指定されていません。 fatal: Need to specify how to reconcile divergent branches. 典型的には、ローカルとリモートの両方に、それぞれ独自のコミットがあります。コミットは変更を記録した単位です。マージで両方の履歴を結合するか、リベースでローカルのコミットを取り込み先の上に作り直すかを決めます。 既存のコミットをそのまま残して結合するなら、今回の操作だけマージを指定できます。 git pull --no-rebase --ff origin main originとmainは例です。実際の接続先と取り込むブランチに置き換えてください。共同開発では、プロジェクトで決めている方法に合わせます。 エラーは取り込み方を決める段階で出る Git 2.51のpull公式文書は、ローカルがリモートより遅れているだけなら早送りし、履歴が分岐していればマージかリベースを指定する必要があると説明しています。早送りは、新しいコミットを作らず、ブランチの先端を既存のコミットへ進める更新です。 Git 2.51.1のpull実装では、早送りできず、現在の履歴が既に取り込み先を含んでいるわけでもない場合に、分岐と判定します。取り込み方が未指定なら、マージやリベースを始める前に終了します。 したがって、このエラーだけでファイルの競合が起きたとは判断できません。ただし、pullの前半にあるfetchは既に実行されています。現在のコミットが変わらなくても、origin/mainなどのリモート追跡情報は更新されている場合があります。 この記事ではGit 2.51.1を使い、共通のコミットからローカルとリモートを別々に進めて確認しました。方式未指定のpullは終了コード128となり、現在のコミットは変わらず、上記のエラーとhint:付きの案内が表示されました。 接続先・分岐・設定を確認する 取り込む対象と現在の状態を確認します。 git status git remote -v git branch -vv git fetch origin git log --oneline --graph --decorate --all git rev-list --left-right --count HEAD...origin/main 最後のコマンドは、二つの履歴のうち片側だけに存在するコミット数を表示します。HEAD側が左、origin/main側が右です。今回の再現では1 1となり、両側に独自のコミットがありました。接続先やブランチ名のエラーが出た場合は、先にその指定を直します。 次に、設定値と、その設定がどのファイルから来ているかを確認します。 git config --show-origin --get pull.rebase git config --show-origin --get pull.ff git branch --show-current 現在のブランチがmainなら、ブランチ専用の設定も確認します。 ...

冒頭まとめ git pullやgit mergeで次のエラーが出る場合、Gitは結合する二つの履歴に共通の祖先となるコミットを見つけられていません。コミットは、変更内容を記録した単位です。 fatal: refusing to merge unrelated histories 通信をやり直すだけでは解消しません。接続先と対象ブランチを確認し、独立した二つの履歴を本当に結合したい場合だけ、--allow-unrelated-historiesを指定します。 git fetch origin git merge --allow-unrelated-histories origin/main originとmainは例です。実際の接続先とブランチ名に置き換えてください。このオプションは履歴の結合を許可するだけで、ファイルの競合を自動で解消するものではありません。 エラーが出る条件とGitの版 Gitのmerge公式文書は、共通の祖先がない履歴の結合を既定で拒否すると説明しています。独立して始まったプロジェクトの履歴を結合するための例外が、--allow-unrelated-historiesです。 この拒否はGit 2.9のリリースノートに記録されています。それ以前の既定動作は、共通の祖先がない履歴の結合も許可するものでした。別に作られた履歴が意図せず既存プロジェクトへ混ざることを防ぐため、動作が変更されました。 git pullでも、取得した履歴をマージで取り込む場合にこの判定が働きます。pullには履歴を組み直すrebase方式もあり、今回のオプションはマージ方式で使うものです。 ファイルの内容が同じでも、別々に作った最初のコミットが同じ履歴になるとは限りません。判断対象はファイルの一致ではなく、コミット間の親子関係です。 接続先と共通の祖先を確認する 最初に、別のプロジェクトを接続先に指定していないかを確認します。 git status git remote -v git branch --show-current git fetch origin git log --oneline --graph --decorate --all git merge-base HEAD origin/main git fetchはリモートの履歴を取得します。この段階では作業中のブランチへマージしません。取得後のorigin/mainと、現在のコミットを表すHEADを比べます。 merge-baseの公式文書によると、このコマンドは二つのコミットの共通祖先を探します。この記事のGit 2.51.1による確認では、独立した履歴に対して標準出力は空、終了コードは1でした。 ただし、出力がないだけで判断しないでください。ブランチ名が誤っているなどのエラーが表示された場合は、先にその問題を直します。 履歴を途中までしか取得していない浅いリポジトリでは、祖先をたどる情報が不足する場合もあります。 git rev-parse --is-shallow-repository trueなら、接続先を確認したうえで履歴全体を取得し、再確認します。 git fetch --unshallow origin git merge-base HEAD origin/main 浅い履歴の取得方法はfetchの公式文書に説明されています。共通の祖先が見つからない理由を確認する前に、結合の許可へ進まないようにします。 別々の初期化で二つの履歴ができる GitHubでREADME付きのリポジトリを作り、手元でも別にgit initしてコミットすると、それぞれ独立した最初のコミットができます。そこへ接続先を追加しても、過去の履歴の親子関係は変わりません。 ...

冒頭まとめ pip installで次のエラーが出たら、使っているPythonがOSやHomebrewなどの管理対象になっている。パッケージ名や要求する版を変える前に、インストール先の環境を確認する。 error: externally-managed-environment × This environment is externally managed 自分のコードから読み込むライブラリは、プロジェクト用の仮想環境に入れる。仮想環境とは、Pythonのパッケージの保存先を分けた環境のこと。コマンドとして使うPython製ツールは、ツールごとに仮想環境を作るpipxを使う方法もある。 sudoで権限を上げたり、--userでユーザー用の保存先へ変えたりしても、この管理対象の検査は解除されない。まずはvenvで環境を分ける手順へ進む。 エラーが出るPythonを確認する エラーを出したPythonと同じ実行ファイルで確認する。以下はmacOS・Linuxでpython3を使っていた場合の例である。 python3 -m pip --version python3 -c "import sys; print(sys.executable); print('venv:', sys.prefix != sys.base_prefix)" python3 -c "import pathlib, sysconfig; p = pathlib.Path(sysconfig.get_path('stdlib')) / 'EXTERNALLY-MANAGED'; print(p); print('marker exists:', p.is_file())" pip --versionの出力にはpipの版と配置先が含まれる。裸のpipコマンドとpython3 -m pipで違うPythonを使っている場合があるため、以後は対象のPythonからpipを呼び出す。 venv: Falseで、標準ライブラリのディレクトリにEXTERNALLY-MANAGEDがあれば、この検査の条件に当てはまる。PyPAの現行仕様は、仮想環境の外であることと、この管理用ファイルの存在を検査するよう定めている。 ファイルは、パッケージを消してよいか調べるためではなく、そのPythonの管理元を確認するために見る。削除はしない。 OSやHomebrewの更新で出る理由 OSやHomebrewは、自分が提供したPythonとパッケージを管理している。そこへpipで別の版を入れると、管理元が想定した構成と食い違う可能性がある。管理用ファイルは、その環境を通常のpip操作で変更しないよう示すものだ。 pipの変更履歴では、このファイルを読む処理が23.0で追加されている。管理用ファイルを置くかどうかはPythonの提供元が決めるため、pipの版が新しいだけで必ず発生するわけではない。 Debian 12のリリースノートは、提供するPythonを外部管理対象にしたことと、ライブラリには仮想環境、アプリにはpipxを使う方針を説明している。Homebrewの現行文書も、現在提供するPythonの外部管理と仮想環境の利用を案内している。 エラー本文は環境ごとに変わる。管理用ファイルの[externally-managed]内にあるErrorや言語別の項目から案内を読むため、Debianのapt案内とHomebrewのbrew案内は同じ文面にはならない。適切な案内を読み取れなければpipの既定文面になる。空のファイルでも、存在による検査自体はなくならない。 venvのPythonからインストールする プロジェクトのディレクトリで、まだ使っていない.venvという名前に仮想環境を作る。 python3 -m venv .venv .venv/bin/python -m pip --version .venv/bin/python -m pip install requests requestsは例なので、必要なパッケージ名に置き換える。実行するコードも、同じ環境のPythonから呼ぶ。 ...

冒頭まとめ ERR_REQUIRE_ESMは、require()でESモジュールを読み込もうとして、その実行環境が読み込みを拒否したときに出ます。ESモジュール(ESM)は、主にimportとexportで読み書きする形式です。CommonJS(CJS)は、require()とmodule.exportsを使う形式です。 最初にエラーに出た読み込み先と読み込み元、実際に使われたNode.jsの版を確認します。自分のCommonJSコードなら、非同期のimport()に書き換える方法があります。依存パッケージ内部で起きているなら、呼び出しているパッケージの対応版も調べてください。 新しいNode.jsは同期的なESMをrequire()で読み込めます。ただし、更新だけで元の使い方が必ず通るわけではありません。戻り値の取り出し方と、依存先を含めたトップレベルのawaitの有無も確認します。 エラーのパスと実行環境を確認する 次は表示例です。パスは説明用で、文言や補足はNode.jsの版によって変わります。 Error [ERR_REQUIRE_ESM]: require() of ES Module /project/lib.mjs from /project/main.cjs not supported. lib.mjsが読み込もうとしたファイル、fromの後ろにあるmain.cjsが読み込み元です。両方のパスを確認すると、自分のコードと依存パッケージ内部のどちらを直す必要があるかを判断できます。 Node.js v22.12.0のエラー生成実装には、.mjsの場合、ESM構文を含む場合、近くのpackage.jsonの"type": "module"によってESMとして扱う場合に応じた補足があります。ただし、補足の種類だけで対処を固定せず、実際のコードと設定も確認します。 失敗した処理と同じターミナルやCIジョブで、次を実行してください。 node -v node -p "process.execPath" node -p "JSON.stringify({execArgv: process.execArgv, NODE_OPTIONS: process.env.NODE_OPTIONS})" 最後のコマンドは、その確認用プロセスの起動引数とNODE_OPTIONSを表示します。npmスクリプトやツールが別途渡す引数は、その実行設定も確認してください。Node.jsを更新したつもりでも、IDE、CI、コンテナでは別の実行ファイルを使っている場合があります。 Node.jsの版による違いを切り分ける 公式の変更履歴では、同期ESMのrequire()対応はNode.js 20.17.0と22.0.0に追加されました。当初は--experimental-require-moduleで有効にする機能でした。 系列・版 同期ESMをrequire()する機能 Node.js 18系 この機能に未対応 20.17.0〜20.18.x 実験的フラグで有効化 20.19.0以降の20系 既定で有効 22.0.0〜22.11.x 実験的フラグで有効化 22.12.0以降の22系 既定で有効 23.0.0以降の系列 既定で有効。無効化設定にも注意 これは機能が導入された境界の表です。古い系列への更新を推奨する表ではありません。更新先は、Node.js公式のサポート状況とプロジェクトの要件を確認して、サポート中のLTS(長期サポート版)から選びます。2026年10月8日の確認では22系と24系がLTS、20系はサポート終了です。 機能を無効化している場合、新しい版でもERR_REQUIRE_ESMが出ることがあります。起動設定やNODE_OPTIONSの--no-experimental-require-moduleなどを確認します。フラグの名称や利用可否は、使用中の版の文書に合わせてください。 公式エラー文書がこのエラーを非推奨としている理由は、同期ESMをrequire()で読み込めるようになったためです。非推奨という表示は、発生頻度や件数の根拠ではありません。 CommonJSを残してimport()に書き換える CommonJSのままESMを読み込むには、import()を使えます。ESMの公式文書も、CommonJS内からESMを読み込む方法として説明しています。 次は外部パッケージを使わない例です。2つのファイルを同じディレクトリへ保存します。 // lib.mjs export default function greet(name) { return `Hello, ${name}`; } export const label = 'example'; // main.cjs async function main() { const { default: greet, label } = await import('./lib.mjs'); console.log(greet(label)); } main().catch((error) => { console.error(error); process.exitCode = 1; }); node main.cjs import()はPromiseを返すため、読み込み完了を待ってから使います。CommonJSのファイル直下にそのままawait import(...)を書かず、この例のようにasync関数内へ入れます。呼び出し側も、結果が非同期で返ることに合わせる必要があります。 ...

冒頭まとめ SSL: CERTIFICATE_VERIFY_FAILEDは、HTTPS接続先の証明書を検証できなかったときに出ます。まず、certificate verify failed:の後ろにある理由を確認してください。発行者の証明書が見つからない場合、期限切れの場合、接続先の名前が違う場合では、直す場所が変わります。 macOSでpython.org版を入れた直後なら、Install Certificates.commandの実行を確認します。社内ネットワークだけで失敗するなら、管理者が提供するCA証明書と、そのPythonが使う設定を確認してください。 verify=Falseで通っても証明書の問題は解消していません。相手の確認を省略しただけなので、検証を有効にしたまま接続できる状態へ直すのが基本です。 エラー文の末尾で原因を切り分ける Python標準のsslでは、次のような表示になります。行番号は説明用で、Pythonの版やビルドによって変わります。 ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1007) SSLCertVerificationErrorはSSLErrorの一種で、Python公式文書ではPython 3.7で追加された例外とされています。Requests経由では、requests.exceptions.SSLErrorの中に証明書検証の失敗が表示されることがあります。 CPythonの実装では、検証結果に応じて末尾の文言を作ります。ホスト名・IPアドレスの不一致にはPython側の説明を使い、それ以外はOpenSSLの検証理由を使います。 末尾にある理由 最初に確認すること unable to get local issuer certificate 信頼するCAの設定と、サーバーが送る中間証明書 self-signed certificate 自己署名証明書を意図して使っているか、信頼設定があるか self-signed certificate in certificate chain 証明書の連鎖と、信頼の起点となるCA certificate has expired 証明書の期限と、実行環境の時計 Hostname mismatch / IP address mismatch URLの名前・IPアドレスと証明書の対象名 発行者を見つけられない理由は、手元のCA不足に限りません。サーバーが必要な中間証明書を送っていない場合もあります。OpenSSLの検証説明に沿って、接続先から信頼するCAまで証明書をたどれるかを確認します。 実行中のPythonと証明書の設定を確認する エラーが出たターミナル、仮想環境、CIジョブ、コンテナの中で確認します。以下のpythonは、失敗した処理で使うPythonのコマンド名に合わせてください。 python -c "import sys, ssl; print(sys.executable); print(ssl.OPENSSL_VERSION); print(ssl.get_default_verify_paths())" sys.executableは実行中のPython、get_default_verify_paths()は既定のCAファイル・ディレクトリや、関連する環境変数名を調べるために使います。Requestsを使っている場合は、そのCAファイルも別に確認します。 python -c "import requests; print(requests.certs.where())" Requestsの公式文書では、CA証明書にcertifiを使うと説明されています。標準のsslとRequestsが同じ信頼設定を使うとは限りません。 ...

冒頭まとめ npm warn EBADENGINEは、パッケージが要求するNode.jsまたはnpmのバージョンを、現在の環境が満たしていないという警告です。最初に、ログのpackage、required、currentを確認します。 通常は警告として表示され、これだけではインストールを止めません。ただし、engine-strict=trueが有効な場合は、同じ不一致でnpm error code EBADENGINEとなり、インストールが停止する場合があります。 警告のままインストールできても、動作確認が済んだことにはなりません。プロジェクトが指定するNode.js・npmの版と、警告に出たパッケージの要件を合わせてから、インストールとテストをやり直してください。 EBADENGINEが示していること パッケージのpackage.jsonには、実行環境の要件をenginesとして記述できます。 { "engines": { "node": ">=24", "npm": ">=11" } } この例はNode.js 24以上、npm 11以上を要求しています。数値は説明用で、すべてのプロジェクトにこの版を推奨するものではありません。 npm公式文書のenginesの説明では、engine-strictが設定されていない場合、この指定は原則として助言的な扱いになると説明されています。 npm-install-checksの実装は、engines.nodeとengines.npmをそれぞれ現在の版と比較し、どちらかが条件を満たさなければEBADENGINEを生成します。Node.jsだけ確認しても、npm側の不一致が残ることがあります。 新しい版なら必ず通るわけでもありません。たとえば>=18 <24という要件では、Node.js 24は範囲外です。要求されている下限と上限の両方を確認します。 警告にある3項目を確認する 表示例は次のとおりです。パッケージ名と値は説明用です。npmの版によって、接頭辞がnpm WARNなどになることがあります。 npm warn EBADENGINE Unsupported engine { npm warn EBADENGINE package: 'example-package@1.2.3', npm warn EBADENGINE required: { node: '>=24', npm: '>=11' }, npm warn EBADENGINE current: { node: 'v22.0.0', npm: '11.0.0' } npm warn EBADENGINE } packageは要件に合わないパッケージと版、requiredはそのパッケージの要求、currentは実行時のNode.js・npmの版です。この例ではnpmの条件は満たしていますが、Node.jsの条件を満たしていません。 失敗した処理と同じターミナルやCIジョブで確認します。 node -v npm -v node -p "process.execPath" バージョン管理ツールを使っている場合、別のターミナルやIDEでは別のNode.jsが選ばれていることがあります。process.execPathは、実際に起動したNode.jsの場所を確認するために使います。 ...

冒頭まとめ pip installで次のエラーが出た場合、pipは指定された要件を満たす配布ファイルを選べていません。 ERROR: Could not find a version that satisfies the requirement demo_probe==99.0 (from versions: 1.0) ERROR: No matching distribution found for demo_probe==99.0 from versions: noneでも、パッケージが公開されていないとは限りません。Pythonの版やOSに合わないファイルが候補から外れた場合、取得先に接続できなかった場合にも、候補が残らないことがあります。 まず、エラーが出た環境で、使っているPythonとpipを確認してください。 python -c "import sys; print(sys.executable); print(sys.version)" python -m pip --version そのうえで、最後の2行より前に出ている接続エラーや候補の除外理由を読みます。名前、版の指定、Pythonへの対応、取得先、OS向けの形式を順に確認すると、直す場所を絞れます。 エラーの意味とfrom versionsの読み方 pipは、取得先から見つけたファイルをすべてインストール候補にするわけではありません。候補選択の公式文書では、リンクから候補を作る段階で、ファイル形式やPythonへの対応などを評価すると説明しています。 pip 26.2.1の実装でも、wheelの対応条件やRequires-Pythonに合わないリンクを除外しています。wheelは、インストール用に用意された.whl形式の配布ファイルです。 そのため、from versionsはPyPIに公開された全バージョンの一覧ではありません。 表示 分かること それだけでは分からないこと from versions: none 表示対象の候補が残っていない パッケージ自体が存在しないのか、環境や取得先の問題なのか from versions: 1.0, 2.0 その版の候補は見つかっている 指定した版や依存関係を満たしてインストールできるか pip 26.2.1の診断処理は、候補の版を集めて一覧を作り、一覧が空ならnoneを表示します。Python要件で除外した版があれば、その案内を先に出す処理もあります。Python要件の不一致が別の診断として出る場合もあり、エラーが常にこの2行になるわけではありません。 冒頭の出力は、CPython 3.12.14とpip 26.2.1で、ローカルに作成した検証用wheelを使って再現したものです。demo_probeは説明用の名前で、PyPIから取得したパッケージではありません。1.0だけがある場所で99.0を要求すると、候補一覧には1.0が出てもインストールには進めませんでした。 パッケージ名とバージョン指定を確認する エラーに出た名前を、利用するライブラリの公式インストール手順と照合します。Pythonのimportに書く名前と、pipに渡す配布名は一致するとは限りません。PyPAの公式ガイドには、PillowをインストールしてPILを読み込む例が示されています。 標準ライブラリを、外部パッケージとしてインストールしようとしていないかも確認してください。知らない名前を別のパッケージに置き換える前に、プロジェクトが何を要求しているかを確かめます。 利用中の取得先で見つかる版は、次で確認できます。requestsは調べたい配布名に置き換えてください。 python -m pip index versions requests このコマンドの公式文書は、Pythonやプラットフォームの条件を指定できることも説明しています。表示結果は実行環境やオプションに左右されるため、PyPIにある全配布ファイルの一覧とは区別してください。 ...

冒頭まとめ importで次のエラーが出た場合、実行中のPythonが指定したモジュールを見つけられていません。 ModuleNotFoundError: No module named 'requests' インストールしたつもりでも、別のPythonや仮想環境で実行していることがあります。まず、エラーが出る環境で次を確認してください。 python -c "import sys; print(sys.executable)" python -m pip --version python -m pip show requests requestsは例です。実際に必要な配布パッケージの名前へ置き換えます。見つからなければ、実行するPythonを指定したうえで、そのPython経由でインストールしてください。 一方、末尾に'http' is not a packageなどが付いている場合は、手元のファイル名が本来のパッケージ名と衝突している可能性があります。再インストールより先に、何を読み込んでいるかを確認します。 エラーメッセージの意味 モジュールは、importで読み込む単位です。パッケージは、内部に別のモジュールを持てる種類のモジュールです。 ModuleNotFoundErrorはImportErrorの一種で、Python 3.6で追加されました。Pythonの例外の公式文書は、モジュールが見つからない場合と、読み込み済みモジュールを記録するsys.modulesにNoneが入っている場合に発生すると説明しています。 文言 意味 No module named 'foo' fooを見つけられない No module named 'foo.bar' foo.barを見つけられない。親の探索にも注意が必要 No module named 'foo.bar'; 'foo' is not a package fooは読み込まれたが、子モジュールを持つパッケージとして扱えない import of foo halted; None in sys.modules sys.modules['foo']がNoneで、読み込みが拒まれている これらの分岐は、CPythonのimportlib実装で確認できます。None in sys.modulesという文言だけで、別スレッドの失敗が原因だとは判断できません。 最後に表示された名前も確認してください。import requestsを実行していても、内部で必要な別モジュールを読み込めずに停止する場合があります。エラーの直前に並ぶファイル名と行番号を読むと、どの読み込みで止まったかが分かります。 最初に実行するPythonとインストール先を確認する sys.executableは、実行中のPythonの場所を示します。python -m pip --versionでは、そのPythonで動くpipの場所を確認できます。 ...

冒頭まとめ terraform planやterraform validateで次のエラーが出た場合、参照先のリソースが現在のモジュールに宣言されていません。 Error: Reference to undeclared resource A managed resource "aws_security_group" "main" has not been declared in the root module. 最初に、説明文の型名aws_security_groupとラベル名mainを確認してください。同じモジュール内にresource "aws_security_group" "main"という宣言があるかを探します。ラベルのタイプミス、data.の付け忘れ、別モジュールのリソースを直接参照していることが主な確認点です。 クラウド上やstateにリソースが存在していても、設定内の宣言の代わりにはなりません。参照している式と、その式から見える宣言を確認する必要があります。 エラーメッセージの意味 通常の管理対象リソースは<型名>.<ラベル名>.<属性名>で参照します。たとえばaws_security_group.main.idでは、aws_security_groupが型、mainがresourceブロックのラベル、idが属性です。 ラベルはTerraformの設定内で使う名前です。AWS側の名前を設定するname = "web-sg"などの値とは別なので、そこが一致していても参照は成立しません。 Terraformの参照の公式文書は、管理対象リソース、データソース、モジュール出力を別の形式として説明しています。 参照先 参照の形式 管理対象リソース aws_instance.web.id データソース data.aws_ami.ubuntu.id 子モジュールの出力 module.network.vpc_id 入力変数 var.instance_count ローカル値 local.common_tags 本体のevaluate_valid.goでは、参照しているモジュールの設定からリソース宣言を探し、見つからなければこの診断を作ります。stateに記録されているかを調べることで、未宣言の参照を有効にする処理ではありません。 最初に型名・ラベル名・読込範囲を確認する エラーに表示されたファイルと行は、問題の参照が書かれた場所です。そこから参照先の宣言を探してください。 resource "aws_security_group" "web"しかないのにaws_security_group.main.idを参照していれば、ラベル名が違っています。エディターの検索で、型名とラベル名をそれぞれ確認できます。 宣言が別ファイルにある場合は、そのファイルの場所も確認します。同じディレクトリの.tf・.tf.jsonは一つのモジュールとして読み込まれますが、サブディレクトリのファイルは自動では取り込まれません。この範囲は設定ファイルの公式文書に明記されています。 たとえば、main.tfと同じ場所のresources.tfへ宣言を移すだけなら同じモジュールです。modules/network/main.tfへ移した場合は別モジュールになるため、元の場所から同じ参照を続けることはできません。 CLIでは通常、コマンドを実行したディレクトリがルートモジュールです。ローカルとCIで結果が違う場合は、実行ディレクトリや-chdirの指定、対象ファイルがCIに含まれているかも確認してください。 タイプミスとdata.の付け忘れを直す タイプミスなら、参照側を実際の宣言に合わせます。次は組み込みリソースterraform_dataを使った説明用の例です。 resource "terraform_data" "web" { input = "example" } output "value" { # 誤り：mainというラベルの宣言がない value = terraform_data.main.output } 宣言をそのまま使う場合は、outputの参照を次のように直します。 ...

冒頭まとめ git pullやブランチの切り替えで次のエラーが出た場合、Gitは未コミットの変更を上書きしないように操作を止めています。 error: Your local changes to the following files would be overwritten by merge: src/config.py Please commit your changes or stash them before you merge. Aborting 最初にgit status、git diff、git diff --cachedで手元の変更を確認してください。変更を記録できるならコミットし、作業途中ならgit stash pushで一時退避します。不要だと確認できた変更だけを破棄してください。 対象はgit add済みの変更に限りません。まだステージしていない追跡ファイルの変更でも止まります。エラーに並んだファイルを確認せずに、リポジトリ全体を強制的に戻す必要はありません。 エラーメッセージの意味 mergeは別の履歴を取り込む操作、checkoutやswitchはブランチを切り替える操作です。切り替え時には次のような文言になります。 error: Your local changes to the following files would be overwritten by checkout: src/config.py Please commit your changes or stash them before you switch branches. Aborting Gitのunpack-trees.cでは、操作の種類に応じて文言を選び、上書きを拒むファイル名を表示します。git switchでも、表示の中ではcheckoutという語が使われる場合があります。 この停止は、未コミットの変更を残せない操作を拒んだものです。変更があるだけで、必ずすべてのmergeやブランチ切り替えが拒まれるわけではありません。ただし、git-mergeの公式文書は、取り込み対象と重なる作業ツリーの変更や、原則としてHEADと異なる索引の変更がある場合の停止を説明しています。 ...