はじめに
サポート中の Harbour Loop ガイドには、ダウンロードリンクの修正が1つ必要です。開発側には、その修正と、未承認の Explorer 改版がすでに含まれています。元の main の作業ツリーには、ステージ済みの写真計画、さらに加えた未ステージの表紙の下書き、未追跡の非公開メモが残っています。
最初のガイド付き実験のワークツリーの方法を使い、既存の保守ブランチにクリーンな作業ディレクトリを用意します。実際のパッチを読み、単独で適用できる1つの修正を選んで、cherry-pick でその変更だけを再適用します。その後、実用的な旧版のダウンロードを試し、改版も未完成の作業もリリースに入っていないことを確認します。
この単元は専用のリポジトリとファイルを初期化し、前の VM は再利用しません。前提は、ターミナル、コミット、ブランチ、log/diff の基礎と、最初のガイド付き実験で学んだリンクされたワークツリーと小さなファイルの概念です。Web サイトのコードやホスティングされたアカウントは不要です。Workspace と Release Desk を使います。実際の Git/HTTP プレビューは1台の学習用マシン内にあり、作業ファイルの編集ではなくブランチのコミットを読みます。経路と人物はすべて架空です。所要時間の40分は、著者による見積もりです。
修正を特定して保守用ワークツリーを開く
このステップでは、期待するダウンロードを確認し、独立した修正を改版と区別して、main を乱さずに既存の旧ブランチを開きます。
Release Desk、続いて Open supported release を開きます。Harbour Loop、Pocket Edition 1.0、3.2 km、North Pier を確認します。Download quick start を使い、ブラウザーのダウンロード一覧から quick-start.txt を開いて、元の集合場所と短い準備リストを確認します。
Download full guide を使います。実際の404 Guide not found ページになることを想定しています。その後、Back to release をクリックします。サービスには接続できていますが、この版のリンクは、含まれていないファイルを指しています。
All releases、続いて Open development preview を使います。Explorer Edition 2.0 は未承認です。こちらの Download full guide は、すでに動作しています。ダウンロード一覧から harbour-guide-v1.txt を開き、元の3つの道順、North Pier の出発点、3.2 km の距離、道とごみについての注意を読みます。改版は含めず、この有用な修正を残してください。All releases で戻ります。
Workspace に切り替え、元の作業ディレクトリへ明示的に移動します。
cd /home/labex/project/release-desk/editor
通常のパスの間違いには、pwd と ls を使い、この完全な cd を実行し直してください。VM をリセットしないでください。リポジトリ内だけで使う作成者情報を設定します。--local は、このリポジトリとリンクされたワークツリーに作用し、グローバル設定には作用しません。引用符で囲んだ架空の例は、置き換えても構いません。
git config --local user.name "Guide Editor"
git config --local user.email "guides@example.com"
保守作業を始める前に、未完成の状態を読みます。
git branch --show-current
git status --short
git --no-pager diff --cached -- preview.txt
git --no-pager diff -- preview.txt
cat private-note.txt
最初の実験と同様に、main、MM preview.txt、?? private-note.txt があるはずです。最初の差分は、ステージ済みの Plan: add dusk photographs. の追加を示します。2つ目は、さらに加えた未ステージの Draft: try the violet cover. の追加を示します。それぞれ異なる内容と非公開メモを保持してください。--cached はインデックスとコミットの比較を選び、通常の diff は作業ファイルとインデックスを比較します。--no-pager は直接出力し、-- は後続のパスを区切ります。
開発側のコミット済み履歴を読みます。--oneline は各項目を短くし、--decorate はポインターとタグにラベルを付けます。
git --no-pager log --oneline --decorate dev-start
固定のタグ dev-start は、引き継いだ main の先端を示します。用意された履歴は、新しい順に Plan the Explorer photo collection、Correct the Harbour Loop download link、Introduce the Explorer redesign、Prepare the supported Harbour Loop guide です。タグと main の先端は変更しないでください。
選ぶ前に、最新の変更を調べます。show は選択したコミットとパッチを表示します。
git --no-pager show dev-start
explorer-plan.txt を変更しています。これは無関係な将来の作業です。修正は、この固定の目印から親を1つ前へたどった位置にあります。~1 は、チェックアウトを変えずにその親を選びます。
git --no-pager show dev-start~1
完全なパッチは、1行の full-guide.path だけを変更します。/downloads/harbour-guid-v1.txt が /downloads/harbour-guide-v1.txt になります。この修正は単独で適用できるものであり、改版を必要としません。その前の改版も調べます。~2 は固定の目印から親への参照を2回たどり、その位置にある1つの祖先コミットを選びます。
git --no-pager show dev-start~2
版の名称を変更し、Explorer の計画を追加しています。開発ブランチ全体をマージすると、有用な修正だけでなく、これらの未承認の変更も入ってしまいます。
main の隣に、既存のサポート中ブランチを開きます。.. は親ディレクトリを指します。2つ目の引数は、main から新しいブランチを作るのではなく、既存のブランチを明示的に選びます。
git worktree add ../supported-v1 release/1.0
git worktree list
cd ../supported-v1
git branch --show-current
git status --short
cat release.txt
Git 本来のワークツリー一覧に両方のディレクトリがあり、ブランチが release/1.0、保守作業の状態がクリーンで、版が Pocket Edition 1.0 であるはずです。独立したインデックスによって、main の下書きをそのまま残しながら、cherry-pick に必要なクリーンな適用先を用意できます。誤って main をもう一度追加しようとしても、最初の実験で学んだチェックアウト済みの拒否には force や reset は不要です。git worktree list を確認し、既存のサポート中ブランチを使ってください。
修正を適用して保持されたリリースを確認する
このステップでは、選択したパッチだけを旧リリースへ再適用し、実際のガイドを試して、元の開発作業が保たれていることを確認します。
引き続き Workspace の /home/labex/project/release-desk/supported-v1 で作業します。cherry-pick は、選択したコミットが導入した変更を現在のブランチに適用し、通常は新しいコミットを記録します。選択したコミットの祖先すべてをマージするわけではありません。この環境では、旧ブランチと元の修正コミットで親が異なるため、新しい修正は独自のコミット ID を持ちます。
古いリンクを一度読み、調べた独立した修正を適用します。リポジトリのオブジェクトと参照は共有されるため、どちらのリンクされたワークツリーからもタグが見えます。
cat full-guide.path
git cherry-pick dev-start~1
競合なしで、ダウンロードリンクの件名を持つ新しいコミットが1つ作成され、1ファイルが変更されるはずです。この用意されたパッチは、サポート中の基準版にある同じ小さな設定を変更し、依存関係の連鎖はありません。コミット ID は異なる場合があります。
保守ブランチに何が加わったかを正確に確認します。固定の supported-start タグは引き継いだ旧版の先端、HEAD はこのワークツリーの現在のコミットであり、diff はそれらのスナップショットを比較します。
git --no-pager diff supported-start HEAD
完全版ガイドのパス修正だけがあるはずです。release.txt、ガイドの内容、元のプレビューテキストに変更はなく、Explorer 専用ファイルもないはずです。実際の履歴と、クリーンな適用先の状態を調べます。
git --no-pager log --oneline --decorate
git status --short
cat release.txt
元のサポート中のコミットの直後に、修正が1つあるはずです。このブランチの祖先履歴には、開発側の改版と写真計画のコミットはありません。成功を決めるのはメッセージの正確なつづりではなく、独立したパッチ、正しい基準版、保持されたファイルです。
Release Desk に切り替え、ヘッダーの Release Desk をクリックして概要へ戻り、Open supported release を開きます。Pocket Edition 1.0、Harbour Loop、3.2 km、North Pier が保持されていなければなりません。ローカルプレビューは、今進めたブランチのコミットを読み取ります。リモートや本番環境へのデプロイを模擬しているわけではありません。
Download full guide をクリックします。ブラウザーのダウンロード一覧から、実際の harbour-guide-v1.txt を開きます。先ほど読んだ開発側のダウンロードと、内容全体を比較します。North Pier の出発点、Clock Steps、古いボートハウス、Anchor Square を通る3つの道順すべて、3.2 km、最後の道とごみについての注意です。修正で届けるのは元のサポート中のガイドであり、新しい Explorer の経路ではありません。ダウンロードリンクだけ、または成功のステータスコードだけでは、内容の完全性を証明できません。
Download quick start を使い、元のチェックリストを保持します。All releases から開発プレビューを開き、Explorer Edition 2.0 が変わっていないことを確認します。All releases で戻ります。
Workspace に切り替え、main の元のディレクトリへ戻ります。別のディレクトリに移ると、コマンドが調べるワークツリーのインデックスも変わります。log の -1 オプションは、最新のコミットだけに出力を制限します。
cd /home/labex/project/release-desk/editor
git branch --show-current
git --no-pager log -1 --oneline --decorate
git status --short
git --no-pager diff --cached -- preview.txt
git --no-pager diff -- preview.txt
cat private-note.txt
最新のコミットは、dev-start が示す元の写真計画のコミットのままでなければなりません。main の元の MM preview.txt と ?? private-note.txt、同じステージ済みの写真計画の文、別の未ステージの紫色の表紙の文、変更されていない非公開メモがあるはずです。ステータスをクリーンにするためだけに、コミットしたり破棄したりしないでください。サポート中のワークツリーは利用できる状態で残します。チェックポイントでは、リンク関係、サポート中の履歴、必要なすべてのファイルを、実際のダウンロードと main の保持とともに確認します。
まとめ
実際の開発パッチを調べ、独立したリンク修正を選んで、クリーンな保守用ワークツリーで cherry-pick によって再適用しました。旧リリースには、改版を取り込まずに有用な修正が1つ入りました。
完全版ガイドとクイックスタートのダウンロードは完全なまま保たれ、開発ブランチの先端、ステージ済みと未ステージの下書きのバージョン、非公開メモもそのまま残りました。独立したチャレンジでは、サポート中のブランチ、ガイド、修正の位置が変わります。オフセットをコピーするのではなく、証拠から選んでください。
