-
Git はソフトウェアに
あなたが加えた修正をすべて追跡します
-
でもreflog を使えば―
-
あなたの修正に対する修正も
追跡できると知っていますか？
-
♪ (なめらかな音楽) ♪
-
Git のユーザーがまず発見するのは
-
レポジトリに行うコミットはすべて
-
瞬間的に記録され
-
コードベースの進行状態を
示すということです
-
しかしGit のもっと上級者なら
reflog によって
-
行われたコミットの履歴だけでなく
-
廃棄されたコミットの履歴も
記録していると気づくでしょう
-
これによって30日間の
ローリングバッファが行われ
-
間違いを修正することができます
-
git reset コマンドを
用いた有害なもの―
-
ブランチの削除や
-
誤って行われたrebase なども
含みます
-
♪ (音楽) ♪
-
Git reset は各ブランチによって
個別のものです
-
より詳しく見ようと思うなら
-
.git フォルダの中に
-
logs というサブカテゴリがあります
-
下位にローカルのレポジトリの
-
各ブランチごとのファイルがあります
-
これらのlogs はそれぞれ
行った変更を
-
時系列の前後両方向に記録しています
-
これに対するユーザーインターフェースが
git reflog コマンドです
-
これは最新の履歴を表示します
-
ページングのメカニズムによって
現在作業を行っているブランチに
-
発生した過去のエントリーを
見せてくれます
-
git reflog を初めて実行して
-
画面上に表示される
履歴を見たら
-
それに対して何ができるのかと
思うかもしれません
-
表示されている
７桁のハッシュ値を選んで
-
コードベースの回復のための
候補として使いましょう
-
このハッシュ値に
git reset -- hard を行うのです
-
これで現在のブランチは
強制的に
-
その時点にまで戻ります
-
♪ (音楽) ♪
-
git reflog が提供する
直線的な履歴は
-
たどるのが難しいかもしれません
-
どれが空ブランチなのか？
-
どれがコードベースに
もう関係のないコミットなのか？
-
ちょっとコマンドラインに
立ち入って操作することで
-
reflog の結果をグラフィカルな
ユーザーインターフェースに表示でき
-
これはgitk と呼ばれます
-
これでどのブランチが
空ブランチであるか―
-
どのコミットがブランチに関係ないか
-
そして回復したいのがどれかがわかります
-
回復には 説明したように
-
ハッシュ値を使って
reset -- hard を使います
-
♪ (音楽) ♪
-
Git reflog によって
頻繁にコミットできるようになります
-
頻繁にコミットを行えば
reflog に履歴が残り
-
リセットやコミットの削除をしたり
-
変更したり 間違っても大丈夫です
-
コミットされていないものは
作業中のディレクトリでも
-
ステージングエリアでも
リスクにさらされていますが
-
コミットされていれば
回復できるのです
-
過去30日間の分は
保険のようなもので
-
他のGit の機能を使うことで
-
大きく大胆な一歩を
踏み出すことがができます
-
♪ (音楽) ♪
-
Git and GitHub Foundationsの
reflog 編を
-
ご覧いただきありがとうございます
-
こちらからチャンネルを購読するのを
お忘れなく
-
質問や効果的な使い方は
-
下で尋ねてください
-
reset に関するものなどの
関連動画も
-
とても役立ちます
-
reflog について学んだことと
一緒に活かせますよ
-
♪ (音楽) ♪
GitHub