Git

冒頭まとめ ブランチを切り替えようとして、次のエラーが出ることがあります。 error: pathspec 'feature/login' did not match any file(s) known to git feature/login は、指定した名前の例です。ブランチへ切り替えるつもりでも、エラーにはファイルという言葉が出ます。 まずブランチ名と接続先を確認し、リモートの状態を取得してから切り替えます。git checkout -b feature/login だけで新しく作ると、相手が作ったブランチではなく、現在のコミットから作ってしまうため、先に切り替え元を確認してください。 ブランチ指定なのにファイルのエラーになる理由 git checkout は、ブランチへの切り替えと、ファイルを戻す操作の両方を担当します。公式文書の名前の解釈にも、この2つの用途が説明されています。 指定した名前がコミットやブランチとして見つからず、リモート追跡ブランチからの自動作成もできなければ、ファイルの指定として処理される場合があります。そのファイルにも一致しないと、本件の文言になります。 pathspecは、Gitに渡すファイルやディレクトリなどの対象指定です。エラー文だけでは、ブランチを指定したかったのか、ファイルを指定したかったのかまでは分かりません。最初に実行したコマンドの目的を確認します。 名前とリモート追跡ブランチを確認する ブランチを切り替えたい場合は、まず次を実行します。 git status git remote -v git branch -a git branch -a でローカルのブランチと、remotes/origin/feature/login などのリモート追跡ブランチを確認します。後者は、リモートの状態を手元に記録したものです。GitHubの画面をその場で問い合わせた一覧ではありません。 名前の綴りと、大文字・小文字を含む正確な表記も確認してください。別のリポジトリや、同僚の個人用リポジトリを見ていないかは、git remote -v のURLと照合します。 未コミットの変更がある場合は、その内容も確認します。名前の問題が解消した後、変更の上書きを防ぐために切り替えが止まることもあります。その場合は、本件とは別の停止理由です。 fetchしてから既存ブランチに切り替える 接続先がoriginなら、次でリモートの状態を取得します。origin以外なら実際の名前に置き換えてください。 git fetch origin git branch -r git fetchの公式文書では、引数で取得するブランチを指定しない場合、リモートのfetch設定に従って取得し、リモート追跡ブランチを更新します。 origin/feature/login が確認できたら、次で切り替えます。 git switch feature/login git switchの説明では、ローカルに名前が無くても、条件に合うリモート追跡ブランチがあれば、ローカルブランチを作成して追跡する動作があります。これは、リモートに直接移動して作業する操作ではありません。 同じ名前が複数のリモートにある場合や、取得元を明示したい場合は、ローカルに同名のブランチがまだ無いことを確認して次を使います。 git switch -c feature/login --track origin/feature/login checkoutを使う場合の同等の指定は、次です。 ...

冒頭まとめ git remote add origin ...で次のエラーが出たら、同じ名前のリモートが既に登録されています。リモートは、取得先や送信先のリポジトリに付ける名前です。 error: remote origin already exists. まず登録済みの名前とURLを確認します。 git remote -v URLが目的のものなら追加し直す必要はありません。既存のoriginのURLを変えたいなら、addではなく次を使います。 git remote set-url origin https://github.com/OWNER/REPOSITORY.git URLは実際の接続先へ置き換えます。元の接続先も残したい場合は、後述する別名での追加を使ってください。 originは登録名であり接続エラーではない GitHubのリモート管理の公式説明は、このエラーを、ローカルリポジトリに存在する名前を再び追加しようとした状態と説明しています。 originは特別なURLやGitHub上のリポジトリ名ではなく、手元で接続先を識別する登録名です。別のURLを指定しても、同じ名前が使われていれば追加は拒否されます。 逆に、同じURLを違う名前で登録することもできます。エラーの判定対象はURLの一致ではなく、名前の重複です。 今回のGit 2.51.1による確認では、clone済みのリポジトリに再びoriginを追加すると、上記の文言と終了コード3になりました。失敗した追加操作の前後で、リポジトリの設定ファイルは変わっていませんでした。 URLの存在やアクセス権を確認する段階のエラーではありません。再試行やパスワード変更だけで、名前の重複がなくなるわけではありません。 登録済みのURLと作業場所を確認する 別のプロジェクトを操作していないかも含めて、現在の対象を確認します。 git rev-parse --show-toplevel git remote -v git remote get-url --all origin git remote get-url --push --all origin --show-toplevelは作業ディレクトリの最上位を表示します。get-urlの後半二つは、取得側と送信側のURLをそれぞれ確認する指定です。 通常の設定例では、git remote -vに次のように表示されます。 origin https://github.com/OWNER/REPOSITORY.git (fetch) origin https://github.com/OWNER/REPOSITORY.git (push) fetchは取得、pushは送信に使うURLです。二行あるだけで、originが二重登録されているという意味ではありません。 cloneの公式文書によると、cloneでは既定で複製元がoriginとして登録されます。clone後に、初期化済みのリポジトリ向けのremote add origin手順を繰り返せば、名前が重なります。clone --originなどで名前を指定した場合は、実際の一覧で判断します。 URLに認証情報が含まれている場合は、確認結果をそのまま公開しないでください。 URLの変更にはset-urlを使う 既存の接続先が誤っている、または同じリポジトリへのHTTPSとSSHを切り替えたい場合は、URLを変更します。 git remote set-url origin https://github.com/OWNER/REPOSITORY.git git remote -v Gitのremote公式文書には、既存リモートのURLを変更するset-urlが説明されています。今回の最小例でも、変更後のURLが表示され、現在のコミットとorigin/mainなどの追跡情報は残りました。 ...

冒頭まとめ git statusやgit addで次のエラーが出たら、まずコマンドを実行している場所を確認します。 fatal: not a git repository (or any of the parent directories): .git Gitが、その場所から利用できるリポジトリを見つけられていません。cloneでできたディレクトリへ移動せず、その親で操作している場合もあります。 cd repo git status repoは実際の保存先に置き換えます。既存のリポジトリを使うつもりなら、エラーを消すためにその場でgit initするのではなく、正しい場所を確認してください。 Gitは現在の場所から親へ探す Gitの公式文書は、現在のディレクトリにリポジトリがなければ、親をたどって探すと説明しています。既定ではファイルシステムの境界を越えません。環境変数によって探索先が指定・制限されている場合もあります。 通常の作業ディレクトリでは、.gitに履歴や設定の管理情報があります。ただし、Gitが探すのは子ディレクトリではありません。Downloads/repoがリポジトリでも、Downloadsからgit statusを実行して、その中のrepoを自動で選ぶわけではありません。 反対に、リポジトリの下にあるrepo/srcからは、通常は親の管理情報を見つけられます。必ず一番上で実行しなければならない、という意味でもありません。 このエラーは、Gitのインストール失敗や通信障害を直接示すものではありません。少なくとも、表示されたGitのコマンドは起動しています。 現在の場所とclone先を確認する macOS・Linux・Git Bashでは、次で現在の場所と隠しファイルを確認できます。 pwd ls -a Windowsのコマンドプロンプトでは次を使います。 cd dir /a リポジトリと思われる場所へ移動し、Git自身に確認させます。 git rev-parse --is-inside-work-tree git rev-parse --show-toplevel rev-parseの公式文書によると、最初の指定は作業ディレクトリ内ならtrueを表示し、後の指定は作業ディレクトリの最上位を表示します。今回のGit 2.51.1による確認では、リポジトリ外の最初のコマンドは、冒頭のエラーで終了コード128となりました。 cloneの公式文書は、新しいディレクトリにリポジトリを複製する操作を説明しています。保存先の名前を明示すると、移動先も分かりやすくなります。 git clone <repository-url> repo cd repo git status <repository-url>は実際のURLへ置き換えます。cloneが失敗していた場合は、その出力を先に確認してください。 場所を移動せずに指定する方法もあります。 git -C repo status -Cは、指定した場所でGitを実行するための指定です。エディターや自動処理から呼んでいる場合も、実際の作業場所がどこになっているかを確認します。 GitHub DesktopのIssue #11413には、指定した親ディレクトリではなく、その下のリポジトリ名のディレクトリに.gitが作られたという報告があります。今回のCLIの全文と同じ表示の報告ではありませんが、保存先の思い違いを確認する関連事例です。 新規管理とZIPからの取得を区別する 自分のファイルを新しくGitで管理し始めたい場合は、対象ディレクトリで初期化します。 cd my-project git init git status initの公式文書は、空のリポジトリを作る、または既存のリポジトリを再初期化する操作と説明しています。新規初期化だけでは、ほかの場所にあった過去の履歴やリモート設定が戻るわけではありません。 ...

冒頭まとめ 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してコミットすると、それぞれ独立した最初のコミットができます。そこへ接続先を追加しても、過去の履歴の親子関係は変わりません。 ...

冒頭まとめ 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と異なる索引の変更がある場合の停止を説明しています。 ...

冒頭まとめ fatal: detected dubious ownership in repository atは、Gitがリポジトリの所有者を確認し、現在Gitを実行している利用者と一致しないと判断したときに発生します。これはファイルを読み書きできないという意味ではなく、所有者の異なるリポジトリを信頼しないための安全機能です。 自分だけが使うフォルダなら、まず所有者を確認し、誤って別の利用者や管理者の所有になっている場合は所有者を直します。共有リポジトリやコンテナのように、所有者が異なる状態を意図している場合は、信頼できるパスだけをsafe.directoryへ登録してください。 git config --global --add safe.directory "<repository-path>" この設定は原因となった所有者の違いを解消するものではありません。指定したリポジトリを例外として信頼する設定です。内容を確認していないリポジトリや、外部から書き換えられるフォルダは登録しないでください。 エラーの概要 表示されるエラーは次の形式です。 fatal: detected dubious ownership in repository at '<path>' To add an exception for this directory, call: git config --global --add safe.directory <path> Gitは通常、Gitを実行している利用者が所有するリポジトリだけを信頼します。所有者が異なる場合、リポジトリ内の設定やフックを読み込む前に処理を止めます。Gitの公式文書では、所有者が異なっていても信頼するディレクトリをsafe.directoryで個別に登録できると説明されています。 このエラーはWindowsだけでなく、Linux、macOS、Dockerなどのコンテナ、CIでも発生します。特に、ファイルを作成した利用者とGitを実行する利用者が異なる環境で起こりやすくなります。 まず所有者と設定を確認する 先にsafe.directoryを追加するのではなく、誰がリポジトリを所有しているかを確認します。 LinuxやmacOSでは、次のコマンドでフォルダの所有者IDと現在の利用者IDを比較できます。 ls -ldn "<repository-path>" id -u WindowsのPowerShellでは、次のコマンドでフォルダの所有者と現在の利用者を確認できます。 (Get-Acl "C:\path\to\repository").Owner whoami /user すでに登録されているsafe.directoryと、その設定が書かれている場所は次のコマンドで確認できます。 git config --show-origin --get-all safe.directory 何も表示されない場合は、safe.directoryが登録されていません。 信頼できるリポジトリだけを登録する 共有フォルダやコンテナのマウント先など、所有者が異なる状態を意図している場合は、対象のリポジトリを個別に登録します。エラーメッセージに表示されたパスを確認し、絶対パスで指定してください。 git config --global --add safe.directory "<repository-path>" Windowsでは、次のようにスラッシュを使ったパスも指定できます。 git config --global --add safe.directory "C:/work/example" 設定を残さず、そのコマンドだけ実行したい場合は-cを使います。 ...