HEADを移動せずに履歴を読み取る

• HEAD、選択したコミット、作成者、コミッターを区別します。
• 親と最初の親の祖先をたどります。
• 2 つのドット/3 つのドットのログ セットを、diff エンドポイントと混同することなく読み取ります。
• 履歴を書き換えずに、GitTree 内の 2 つの実際のコミットを比較します。

レッスン 7 が終了したところから開始します。main にはレッスン 5 から 7 までの 3 つのコミットがあります。CSS 半径のみが変更されたままになります。HEAD とインデックスは CSS-02-INDEX、作業ファイル CSS-02-WORKING を保持します。リモコンはありません。このビデオは、Ubuntu 24.04 の Git 2.52.0 と GitTree 2.0 を使用して録画されました。両方のコミット、ドキュメント、グラフ検査、検索、HEAD へのジャンプと参照の比較がアプリで操作され、ターミナル チェックがアプリが作成したものに対して実行されたため、表示されるコミット ID はアプリが比較したものです。分岐ブランチのケースは図です。機能ブランチは作成されませんでした。 macOS または Windows では何も実行されず、記録された Linux システムは Ubuntu だけです。 GitTree のソース最小値は Git 2.39.0 です。サインインすると、ローカル検査とコミットは無料プランで行われます。

コミットでは、ツリー、メタデータ、および親 ID が記録されます。ブランチはコミットに名前を付けます。通常、HEAD は現在のブランチに名前を付けます。グラフの別の行をクリックすると、HEAD、ブランチ、またはディスク ファイルではなく、アプリの selection が変更されます。著者は作品を書いた人を記録します。 committer は、このコミットを記録した人を記録します。ここでは、彼らはたまたま同じ架空のアイデンティティです。

線形チェーンの場合、HEAD~1 は 1 つの最初の親エッジに従います。 HEAD~2 は 2 に続きます。 HEAD^1 は最初の親です。 HEAD^2 は、「2 つのコミットバック」ではなく、second parent of one commit を意味します。非マージコミットには 2 番目の親がありません。

git log A..B は、A からの到達可能性を除く、B からの到達可能性を意味します。git log A...B は、到達可能性の対称的な差を意味します。 git diff A B はエンドポイント ツリーを比較し、git diff A...B は merge-base(A,B) と B を比較します。 3 つの点のログと 3 つの点の差分は同じ質問をするわけではありません。この線形履歴では、いくつかの結果がたまたま一致します。その偶然の一致を枝分かれに一般化しないでください。 リビジョン表記、差分セマンティクス。

読み取り/選択/検索では、インデックス、作業バイト、または参照は変更されません。このレッスンの 2 つの明示的なコミットは、ローカル メインを移動します。最初に radius、2 番目にドキュメントを移動します。リモート変更はありません。

まず、以下に示すように、既存の半径編集をコミットします。次に、この完全な UTF-8/LF 本文を使用して docs/history.md を作成します。最後の項目では、作成された SHA ではなく、ドキュメントを含むコミットについて説明します。

# GitTree Features history

The first-parent chain on main, oldest first:

1. feat: add the GitTree Features hero
2. feat: add styling and local project checks
3. feat: refine the hero and card spacing
4. style: finish the card radius change
5. docs: record logs-and-revisions practice

After this document is committed, HEAD names item 5.
HEAD~1 names item 4; HEAD~2 names item 3.
Selecting a graph row does not move HEAD.
These labels are descriptions, not fabricated commit SHAs.

All identities in this project are fictional.

この 5 つのコミット チェーンに、オプションの練習ノートブックや追加のクリーンアップ コミットを追加しないでください。

1. パレット Show Working Changes (パレットを開くには Command/Ctrl+Shift+P)。 Unstaged Filesの下にあるstyles.cssをクリックします。半径 0.5rem → 0.75rem だけが残っていることを確認します。以前の幅の変更を繰り返さないでください。
2. Stage File 行アクションを選択し、概要 style: finish the card radius change を入力し、通常のオプションをオフにしてから、Commit Changes to 1 File (または Command/Ctrl+Enter を 1 回押します)。 4 つのコミットを確認し、追跡ステータスをクリーンアップします。
3. パレット New File… → Path from the project folder = docs/history.md → Create。ドキュメント全体を貼り付けて、Save。 Back to Graph → Show Working Changes → docs/history.md のステージ ファイル。
4. 概要 docs: record logs-and-revisions practice; 1 つのファイルをコミットします。予想されるチェーンには現在 5 つのコミットがあります。
5. ルート ヒーローの行をクリックします。コミットの詳細で、実際の SHA、件名、作成者/コミッター、および root commit の親ステータスを検査します。最新の行をクリックします。その親関係を比較します。単に読み取るためだけに Check Out This Commit を呼び出さないでください。
6. コミットの詳細で View all files を切り替えて、コミットのツリー全体と変更されたパスのみを区別します。記録されたリビジョンで文書を検査します。これによって作業ファイルは変更されません。
7. Back to Graph を返します。パレット Search Loaded History または Command/Ctrl+F while the graph is active を使用し、radius と入力して、一致するロードされた履歴を調べます。エディターでは、同じコードがエディター テキストを検索します。その後検索をクリアしてください。ロードされた履歴の検索は、サーバー全体の履歴クエリではありません。
8. パレット Jump to HEAD、Command/Ctrl+Shift+H、現在のチップを見つけます。ネイティブ git symbolic-ref --short HEAD がメインをレポートしている間、選択/検索は移動できます。
9. ネイティブ git rev-parse HEAD~2 を使用して、その real コミット ID を取得します。固定コースの SHA は提供されません。パレット Compare References… (repo.compareRefs) が Compare References を開きます。 Old side に、測定された ID を貼り付け、そのコミット オプションを選択します。 New side で HEAD を選択します。ピッカーはコミット ID を受け入れますが、そこで任意のリビジョン式が解析されることを約束するものではありません。
10. What to compare で、The two endpoints を選択し、次に Compare を選択します。このチェーンでは docs/history.md と style.css の違いが予想されます。比較を再度開くか変更して、同じ辺を持つ Changes since the merge base を選択します。線形祖先により、ここでエンドポイントの結果が一致します。そのビューから対称ログの動作を推測しないでください。 Cancel は履歴を変更せずに終了します。

対応するアプリが成功する前にのみ、ネイティブのミューテーションの代替:

git add -- styles.css
git commit --quiet -m "style: finish the card radius change"

どちらも静かに成功しました。ドキュメント全体を保存した後:

git add -- docs/history.md
git commit --quiet -m "docs: record logs-and-revisions practice"
git log --reverse --format=%s

完全に観察されたチェーン:

feat: add the GitTree Features hero
feat: add styling and local project checks
feat: refine the hero and card spacing
style: finish the card radius change
docs: record logs-and-revisions practice

セットとツリーを検査します。

git log --format=%s HEAD~2..HEAD
git log --format=%s HEAD~2...HEAD

各クエリは個別に出力されます。

docs: record logs-and-revisions practice
style: finish the card radius change

これらが一致するのは、古いエンドポイントがここでは祖先であるためです。

git diff --name-only HEAD~2 HEAD
git rev-list --count HEAD
git symbolic-ref --short HEAD

順番に出力します。

docs/history.md
styles.css
5
main

2 つの名前付きファイルはツリーの違いであり、ログによって返された 2 つのコミットの同一性ではありません。

git rev-parse --verify --quiet HEAD^2

stdout/stderr がないことが確認され、1 が終了しました: 最新のコミットはマージではありません。代わりに、2 つの最初の親ステップには HEAD~2 を使用してください。実際の比較 ID を特定するには:

git rev-parse HEAD~2

リハーサル中に実際の出力を読んでください。測定された SHA はコミット メタデータによって変化するため、モデル ラベルからコピーしてはなりません。

このレッスンの終わりには、文書化された順序でメインに 5 つのコミットを行います。追跡された作業/インデックスはクリーンで、リモートまたは進行中の操作はありません。 CSS の半径は 0.75rem になり、docs/history.md がコミットされます。過去のグラフ行を読み取っても HEAD が切り離されていません。

• 選択した行をチェックアウトされたコミットとして扱う: HEAD を個別に検査します。
• ^2 を ~2 として読み取る: 2 番目の親と 2 つの最初の親エッジ。
• 対称対数の意味を 3 つのドット diff に適用すると、diff はマージ ベースから右への方向になります。
• グラフ検索がアンロード/アンフェッチされた履歴をカバーすると仮定します。

リビジョンが欠落しているということは、破損ではなく、不十分な祖先、タイプミス、境界が浅いことを意味している可能性があります。チェーンと選択したリポジトリを確認します。コミットを終了する前にアプリフィルターをクリアすると消えます。選択範囲を修復するためだけに、任意のプロバイダーからフェッチしたり、リセットまたはチェックアウトしたりしないでください。ドキュメントがすでに存在する場合は、この新規ファイル手順を適用する前に、その内容を検査してください。

各質問に答えてから、その理由を読みましょう。 「必須」とマークされた質問は、レッスンの完了にカウントされます。

1. 質問 1 / 6

   質問 1 / 6

   古いグラフの行をクリックするとどうなるでしょうか?

   答えを 1 つ選択してください。

   アプリの選択を変更します

   新しいコミットを削除します

   HEADを切り離す

   答えを確認する
2. 質問 2 / 6

   質問 2 / 6

   この 5 つのコミットの線形チェーンに関して正しいステートメントはどれですか?

   当てはまるものをすべて選択してください。

   HEAD^2 は 2 番目の親を意味します

   ^2 は常に ~2 に等しい

   HEAD~2 は 2 つの最初の親エッジに従います

   答えを確認する
3. 質問 3 / 6

   質問 3 / 6必須

   History.md がコミットされた後、HEAD~2..HEAD に含まれるサブジェクトはどれですか?

   答えを 1 つ選択してください。

   HEAD という名前のファイルのみ

   5 つのコミットすべて

   歴史文書と半径

   答えを確認する
4. 質問 4 / 6

   質問 4 / 6必須

   メインは H5 です。特徴 F は H3 から派生したものです。 git ログの主な機能は何ですか?

   答えを 1 つ選択してください。

   H4、H5、F

   Fのみ

   H3のみ

   答えを確認する
5. 質問 5 / 6

   質問 5 / 6

   git diff A...B は対称ログセットを意味しますか?

   答えを 1 つ選択してください。

   いいえ、ベース → B ツリーをマージします

   常に頭が動く

   はい、どこでも同じ演算子です

   答えを確認する
6. 質問 6 / 6

   質問 6 / 6必須

   チェックポイントが完了したことを証明する観察はどれですか?

   当てはまるものをすべて選択してください。

   選択後も HEAD がメインです

   ダーティ半径はまだ保留中です

   正確な 5 つの主題を順番に並べる

   答えを確認する

古い行を選択して、HEAD がメインのままであることを証明します。 2 つのログ エントリが 2 つのパスのみの違いに対応できる理由を説明してください。入力の変更: main が H5 にあるときに H3 からの 1 つのコミットを持つ別のブランチの場合、main..feature にはそのフィーチャーのコミットのみが含まれると予測されますが、main...feature には H4/H5 も含まれます。正規チェックポイントにそのブランチを作成しないでください。使い捨てのコピーを使用します。

• 選択と HEAD の所有者は異なります。
• 親表記とリビジョン セットは、ファイルの変更ではなく、祖先を記述します。
• 実際に解決されたエンドポイントを比較し、質問に明確にラベルを付けます。

• ファイル全体ではなく、選択したハンクをコミットします (レッスン 7)
• 目的のスナップショットをステージングし、最初のコミットを行う (レッスン 5)
• ダウンロード GitTree

コミット — 認証;親 — إيداع أب;参照 — 重要;改訂 — مراجعة;範囲 — 範囲;ベースをマージします — マージベース著者 — ヤステル;コミッター — المُودِع。