Git Reflog
このページでは、git reflog コマンドについて詳しく説明します。Git では、参照ログ、または「reflog」と呼ばれるメカニズムを使用して、ブランチの先端に対する更新を記録します。多くの Git コマンドでは、コミットを示す参照または「ref」を指定するパラメーターを使用できます。一般的な例:
Reflogs は、ローカル リポジトリでいつ Git refs が更新されたかを記録します。Git stash 内には、ブランチ tip reflog 以外に、特別な reflog が格納されています。Reflogs は、ローカル リポジトリの .git ディレクトリ内に保存されています。git reflog ディレクトリは .git/logs/refs/heads/.、.git/logs/HEAD、および .git/logs/refs/stash にあります。git stash がリポジトリで使用されている場合。
git reflog の詳細については、「履歴の書き込み」ページに記載されています。このドキュメントでカバーされている内容: git reflog の拡張構成オプション、git reflog の一般的な使用事例と落とし穴、git reflog で変更を元に戻す方法など。
基本的な使用法
最も基本的な Reflog 使用事例が呼び出されます。
git reflog基本的には、以下と同等のショートカットです。
git reflog show HEADこれにより、HEAD reflog が出力されます。出力は次のようになります。
eff544f HEAD@{0}: commit: migrate existing content
bf871fd HEAD@{1}: commit: Add Git Reflog outline
9a4491f HEAD@{2}: checkout: moving from main to git_reflog
9a4491f HEAD@{3}: checkout: moving from Git_Config to main
39b159a HEAD@{4}: commit: expand on git context
9b3aa71 HEAD@{5}: commit: more color clarification
f34388b HEAD@{6}: commit: expand on color support
9962aed HEAD@{7}: commit: a git editor -> the Git editor
関連資料
Git チートシート
ソリューションを見る
Bitbucket Cloud での Git の使用方法についてのチュートリアルです。
一般的な reflog アクセスについては、履歴ページの書き換えをご覧ださい。
Reflog の参照
DevOps は、開発と運用のライフサイクルのあらゆる段階に対応します。計画と構築から監視と反復にいたるまで、DevOps はエンジニアリングと IT 組織のあらゆる側面のスキル、プロセス、ツールを 1 つにまとめます。
アジャイル手法によって作業を管理可能なタスクとマイルストーンに分割することで、チームが計画して生産できるようにします。アジャイルは、スプリント、バックログ、エピック、ストーリーを利用して、熟練したチーム メンバーに作業を割り当てて必要に応じてタイムラインを調整し、高品質の製品とサービスを顧客に提供します。アジャイルの詳細についてご参照ください。
継続的インテグレーションとデリバリー: 継続的インテグレーションとデリバリーは DevOps プラクティスの基盤であり、コードのマージとデプロイの自動化を活用しています。従来の開発方法では、エンジニアはコードベースの変更を手動でアップデートする必要があり、品質コードが本番環境にリリースできる状態であることを確認するための追加の手動チェックが必要でした。デプロイは、バグやインシデントの可能性を排除するために、数週間または数か月の遅延でスケジュールされます。DevOps プラクティスはマージ、テスト、デプロイの機能を自動化することで、これらの遅延を取り除きます。パフォーマンスの高いチームは CI/CD を使って、デプロイ頻度を数か月ごとから 1 日複数回にします。CI/CD の詳細はこちらをご覧ください。
Git リポジトリとワークフローは、DevOps プラクティスの基礎となる自動化機能とバージョン管理機能を有効にします。Git は分散型であるため、commit、blame、diff、merge、log などの操作が高速で行われます。また、Git はリポジトリ履歴のブランチ作成、マージ、書き換えもサポートしているため、強力なワークフローとツールを実現します。Git の詳細についてご参照ください。
IT サービス管理 (ITSM) とは、IT チームが、顧客に対するエンドツーエンドの IT サービスの提供を管理するプロセスです。これには、IT サービスを設計、作成、提供、サポートする際のすべてのプロセスとアクティビティが含まれます。ITSM のコア コンセプトは、IT を基本的な IT サポートだけに留まらないサービスとして提供する必要があるという信念です。ノート PC からサーバー、ビジネスにとって不可欠なソフトウェア アプリケーションまで、ITSM チームはあらゆる種類のワークプレース テクノロジーを管理します。ITSM の詳細についてご参照ください。
インシデント管理チームは予期しないイベントまたはサービス中断に対応して、サービスを運用状態に復元します。「構築した者が運用する」モデルでは、開発者は運用チームと連携してインシデントが発生する可能性を減らし、インシデントが発生した際の平均復旧時間も短縮します。インシデント管理の詳細についてご参照ください。
既定では、git reflog は HEAD ref の reflog を出力します。HEAD は、現在アクティブとなっているブランチの記号参照です。reflog は他の ref でも使用できます。git ref へアクセスするための構文は name@{qualifier} です。HEAD ref 以外にも、他のブランチ、タグ、リモート、および Git stash を参照することができます。
以下を実行し、すべての ref の完全な reflog を取得できます。
git reflog show --all
git reflog show へブランチ名を渡す特定のブランチの reflog を見るには
[新しいリポジトリの作成] ページが表示されます。少し時間をかけてダイアログの内容を確認します。このページで入力する内容は、リポジトリ タイプを除いてすべて後から変更できます。
git reflog show otherbranch
9a4491f otherbranch@{0}: commit: seperate articles into branch PRs
35aee4a otherbranch{1}: commit (initial): initial commit add git-init and setting-up-a-repo docsこの例を実行すると、otherbranch ブランチの reflog が表示されます。以下の例では、git stash コマンドを使用して、いくつかの変更に stash を行ったと想定しています。
git reflog stash
0d44de3 stash@{0}: WIP on git_reflog: c492574 flesh out introGit stash の reflog を出力します。返された ref ポインターは他の Git コマンドに渡すことができます。
git diff stash@{0} otherbranch@{0}実行すると、このコードによって、stash@{0} の変更を otherbranch@{0} ref が比較され、Git diff 出力が表示されます。
時間付の reflog
すべての reflog エントリにはタイムスタンプが添付されています。これらのタイムスタンプは、Git ref ポインター構文の qualifier トークンとして使用できます。これによって、時間別に Git reflog をフィルタリングすることができます。利用可能な時間修飾子の例をいくつかに以下に示します。
1.minute.ago1.hour.ago1.day.agoyesterday1.week.ago1.month.ago1.year.ago2011-05-17.09:00:00
時間修飾子は組み合わせることができ (例: 1.day.2.hours.ago)、複数形も使用できます (例: 5.minutes.ago)。
時間修飾子の ref は他の git コマンドに渡すことができます。
git diff main@{0} main@{1.day.ago} この例では、1 日前の main に対する現在の main ブランチを差分しています。この例は、タイム フレーム内で発生した変更を把握する際に便利です。
サブコマンドと構成オプション
git reflog では、サブコマンドと見なされるいくつかの追加引数を使用できます。
表示 - git reflog show
show は、既定により、暗示的に渡されます。たとえば、次のようなコマンドの場合:
git reflog main@{0} は次のコマンドに相当します。
git reflog show main@{0}
さらに、git reflog show は git log -g --abbrev-commit --pretty=oneline のエイリアスです。git reflog show を実行すると、 渡された
期限切れ - git reflog expire
expire サブコマンドは、古い reflog エントリやアクセスできないできない reflog エントリを整理します。expire サブコマンドを使用すると、データが失われる可能性があります。このサブコマンドは一般的に、ユーザーではなく、git 内部で使用します。-n または --dry-run オプションを git reflog expire に渡すと、「dry run」が実行されます。これにより、どの reflog エントリに prune とマークされるかが出力されますが、実際にはそれらに対して prune は実行されません。
既定では、直近の有効期限は 90 日に設定されています。コマンド ライン引数 --expire=time を git reflog expire に渡すか、gc.reflogExpire の git 構成名をｓっていすることで、有効期限を指定できます。
削除 - git reflog delete
delete サブコマンド自体は明示的であり、reflog エントリ内で passed を削除します。expire と同様に、delete を使用するとデータが失われる可能性があり、一般的にエンド ユーザーによって呼び出されることはありません。
失われたコマンドを復活させる
リバースやコミットの変更などの履歴書き換え操作を実行した場合であっても、Git で何かが失われることはありません。次の例では、リポジトリにいくつかの新しい変更を加えたと想定します。git log --pretty=oneline は次のようになります。
338fbcb41de10f7f2e54095f5649426cb4bf2458 extended content
1e63ceab309da94256db8fb1f35b1678fb74abd4 bunch of content
c49257493a95185997c87e0bc3a9481715270086 flesh out intro
eff544f986d270d7f97c77618314a06f024c7916 migrate existing content
bf871fd762d8ef2e146d7f0226e81a92f91975ad Add Git Reflog outline
35aee4a4404c42128bee8468a9517418ed0eb3dc initial commit add git-init and setting-up-a-repo docs次に、これらの変更をコミットして以下を実行します。
#make changes to HEAD
git commit -am "some WIP changes"新しいコミットを追加すると、ログは次のようになります。
$ git clone
https://emmap1@bitbucket.org/emmap1/bitbucketstationlocations.git
Cloning into 'bitbucketspacestation'...
fatal: could not read
Password for 'https://emmap1@bitbucket.org': No such file or directoryこのエラーが表示されたら、コマンドラインに以下を入力します。
37656e19d4e4f1a9b419f57850c8f1974f871b07 some WIP changes
338fbcb41de10f7f2e54095f5649426cb4bf2458 extended content
1e63ceab309da94256db8fb1f35b1678fb74abd4 bunch of content
c49257493a95185997c87e0bc3a9481715270086 flesh out intro
eff544f986d270d7f97c77618314a06f024c7916 migrate existing content
bf871fd762d8ef2e146d7f0226e81a92f91975ad Add Git Reflog outline
35aee4a4404c42128bee8468a9517418ed0eb3dc initial commit add git-init and setting-up-a-repo docsこの時点で、以下を実行して main ブランチに対するインタラクティブなリベースを実行します。
git rebase -i origin/mainrebase 中、s rebase サブコマンドを使用して squash するｺﾐｯﾄをマークします。rebase 中、いくつかのコミットを、最新の「一部の WIP 変更」コミットへまとめます。
コミットをで squash を実行したため、git log 出力は次のようになります。
40dhsoi37656e19d4e4f1a9b419f57850ch87dah987698hs some WIP changes
35aee4a4404c42128bee8468a9517418ed0eb3dc initial commit add git-init and setting-up-a-repo docsこの時点で git log を調べると、squash をマークしたコミットはなくなったように見えます。squash を実行したコミットの 1 つを操作したい場合はどうすればよいでしょうか。履歴に対する変更を削除するのでしょうか。このときに、reflog を利用します。
git reflog
37656e1 HEAD@{0}: rebase -i (finish): returning to refs/heads/git_reflog
37656e1 HEAD@{1}: rebase -i (start): checkout origin/main
37656e1 HEAD@{2}: commit: some WIP changesrebase の最初と最後には reflog エントリがあり、そのさらに前には先程の「一部の WIP 変更」コミットがあります。reflog ref へ git reset と渡し、rebase の前のコミットへとリセットできます。
git reset HEAD@{2}この reset コマンドを実行すると、HEAD を、「いくつかの WIP 変更」が追加されたコミットへと移動し、他のスカッシュされたコミットを基本的に復元します。
要約
このチュートリアルでは、git reflog コマンドについて説明しました。カバーされているいくつかの重要なポイントを次に示します。
- 特定のブランチの reflog を表示するには
- reflog を使用して git rebase をもとに戻すには
- 時間ベースの reflog エントリを指定および表示するには
We briefly mentioned that git reflog can be used with other git commands like git checkout, git reset, and git merge. Learn more at their respective pages. For additional discussion on refs and the reflog, learn more here.
この記事を共有する
次のトピック
おすすめコンテンツ
次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。
Bitbucket ブログ
DevOps ラーニング パス
