Gitのdetached HEAD：離れる前にコミットを保つ

例と前提条件

例では古いリリースを一時的にチェックアウトし、作った2個のコミットを修正ブランチとして保ちます。進行中のrebaseや、意図的にdetachedになるsubmoduleとは別の状況です。まずstatusを読み、進行中の操作があれば意図して完了または中止してから、この手順を使います。

変更前に状態を確認する

通常のdetached状態ではbranch --show-currentは空です。statusは状態を説明し、logは現在の確定済み履歴を示します。HEADのIDを記録します。名前が空でも、ブランチがない、ファイルが未追跡である、とは限りません。参照と作業ファイルは異なる情報です。

git status
git branch --show-current
git log -3 --oneline
git rev-parse HEAD

参照または別のチェックアウトを保つ

必要なコミットにいる間にswitch -cでrescue/detachedを作ります。その履歴は到達可能になりますが、未ステージの編集がコミットになるわけではありません。必要なら編集を別途確認してコミットします。既存ブランチを強制置換せず、新しい名前を使ってください。

git switch -c rescue/detached
git branch --show-current

最初の手順

作成後にブランチ名、コミット、差分を確認します。そこで開発を続けるか、mergeまたはcherry-pickで必要な修正を別ブランチへ統合できます。cherry-pickは変更を新しいコミットへコピーし、mergeは履歴を結合します。目的に合わせて選び、結果を確認します。離れるだけなら自動pushは不要です。

git log -3 --oneline --decorate
git show --stat HEAD

別の結果を意図して選ぶ

すでに離れた場合は、ローカルreflogと候補のshowを確認します。差分と親が正しいIDを選び、そこにrescue/recoveredを作ります。VERIFIED_COMMITは確認したIDに置き換える記号です。後続操作で該当エントリが変わるため、HEAD@{1}が必ず失ったコミットとは限りません。

git reflog --date=iso
git show VERIFIED_COMMIT
git branch rescue/recovered VERIFIED_COMMIT

制限と例外

reflogはローカル参照の移動記録で、リモートの保管庫ではありません。エントリや到達不能オブジェクトは期限切れや削除の対象です。未コミットの編集はコミットとして記録されていません。編集だけを失った場合は、事前のエディタバックアップや検証済みstashなどを探し、reflogで必ず再現できるとは考えないでください。

競合と後片付け

submoduleは親が固定したコミットを利用するため、detached HEADになることがよくあります。依存関係を使うだけなら正常です。子を開発するなら、そのリポジトリ内で独自のブランチを作り、子の貢献手順に従います。親のブランチが子コミットを自動で参照するわけではありません。

結果を確認する

救出用ブランチを消す前に、必要なコミットに別の永続ブランチや確認済みmergeから到達できるか確認します。移動先の状態と差分を読み、レビュー中は参照を残します。ブランチ名は確定済み履歴の参照であり、すべてのファイルの物理的な予備コピーでもテスト成功の証明でもありません。

git log --oneline --decorate rescue/detached
git status --short

よくある質問

エラーでしょうか。コミット、tag、固定submoduleを意図して調べる場合は違います。コミットはできますが、残したい履歴には離れる前に名前を付けます。後で復元できることもありますが、オブジェクトとローカル記録が残る場合に限り、永久保存は保証されません。

FluxGitで操作を確認する

FluxGitの履歴と差分の表示で、操作と関連コミットを確認してください。この例のブランチ、共有履歴、ローカルファイルのチェックは維持します。現在利用できるビルドと対応プラットフォームはダウンロードページで確認できます。

Git公式ドキュメント

• git-switch
• git-reflog
• git-branch