はじめに
Waymark は、コンパクトな散策ガイドを公開しています。サポート中の Harbour Loop 版には、まだ完全版ガイドのリンク切れが残っています。新しい Explorer デザインは開発中で、main の作業ディレクトリには、ステージ済みの作業と、さらに加えた未ステージの下書きがあります。非公開メモも公開せずに残す必要があります。
まず正常なクイックスタートのダウンロードで、通常の結果を確認します。その後、未完成の作業の隣に、既存の保守ブランチをリンクされたワークツリーとして開き、小さなリンク設定を修正して、元の下書きを変えずに実用的な旧版のダウンロードを確認します。
前提は、ターミナルでの基本的な移動、コミット、ブランチ、簡単な log/diff の読み取りです。Web サイトのプログラミング、ホスティングされたアカウント、Git サーバーは不要です。用意された Workspace と Release Desk のタブを使います。これは、1台の学習用マシン上にある実際の Git ワークツリーと HTTP プレビューです。プレビューは名前で指定されたブランチのコミットを読み取り、未コミットのファイルは読みません。本番環境へのデプロイではありません。経路、人物、ガイドの文章は架空です。所要時間の35分は、著者による見積もりです。
リリースを確認してワークツリーを開く
このステップでは、正常なダウンロードを確認し、リンク切れを観察して、そのまま残すべき未完成の作業を正確に把握します。
Release Desk を開きます。2枚のカードがある概要画面で、Open supported release をクリックします。ページには Harbour Loop、Waymark Pocket Edition 1.0、3.2 km、North Pier が表示されるはずです。このコンパクトな版は引き続きサポート中です。その版の名称やガイドの内容を Explorer に置き換えるわけではありません。
Download quick start をクリックします。ブラウザーのダウンロード一覧から quick-start.txt を開きます。Harbour Loop を示し、North Pier に集合するよう案内し、水と歩きやすい靴について記載されているはずです。この正常なダウンロードで、通常の結果を確認します。
Download full guide をクリックします。Guide not found と表示される404ページになることを想定しています。 選択したリリースには、リンク先のファイルがありません。サイトに接続できない状態とは異なります。エラーページの Back to release をクリックします。後でバージョン管理されたリンクを調べ、修正します。
サポート中の版のページで All releases、続いて Open development preview をクリックします。ページには、新しい版の名称と形式で、Waymark Explorer Edition 2.0、Harbour Loop、3.2 km、North Pier が表示されます。これらのデザイン変更は未承認であり、サポート中の版の要件ではありません。All releases で戻ります。
Workspace に切り替え、元の作業ディレクトリへ移動します。
cd /home/labex/project/release-desk/editor
cd は、このターミナルのディレクトリだけを変更します。パスを打ち間違えた場合は、pwd で現在地を表示し、ls でそのディレクトリを一覧表示してから、上の完全な cd を実行し直してください。通常の移動ミスに VM のリセットは必要ありません。
このリポジトリだけで使う作成者情報を設定します。--local はグローバル設定を変更せず、引用符は空白を含む名前を1つにまとめます。以下の架空の値は、置き換えてもよい例です。リポジトリ内の設定は、このリポジトリのリンクされたワークツリー間で共有されます。個別に持つインデックスとは異なります。
git config --local user.name "Guide Editor"
git config --local user.email "guides@example.com"
状態を調べます。--short は簡潔な一覧を表示し、branch --show-current はチェックアウト中のブランチを表示します。
git status --short
git branch --show-current
MM preview.txt、?? private-note.txt、ブランチ main が表示されるはずです。2列の短いステータスでは、最初の M がステージされた変更、2つ目の M が作業ファイルにさらに加えられた変更を意味します。?? は未追跡ファイルを意味します。
異なる2つの変更を読みます。--no-pager はスクロールするビューアーを開かずに直接出力します。--cached は、Git のステージングエリアであるインデックスを現在のコミットと比較します。この指定がなければ、diff は作業ファイルとインデックスを比較します。-- はオプションと後続のファイルパスを区切ります。
git --no-pager diff --cached -- preview.txt
git --no-pager diff -- preview.txt
ステージ済みの追加は Plan: add dusk photographs. です。さらに加えた未ステージの追加は Draft: try the violet cover. です。両方のバージョンを別々に残す必要があります。コミット、破棄、1つへの統合は、この保守作業の目的ではありません。
非公開メモを変更せずに読みます。cat はファイルを表示します。
cat private-note.txt
Do not publish supplier prices. を未追跡のメモとして残してください。この作業を消してステータスをきれいに見せても、成功ではありません。次に、保守作業専用のディレクトリとインデックスを用意します。
独立した保守用ワークツリーを開く
ここでは、未完成の main の作業の隣に、既存のサポート中ブランチを開きます。ブランチがすでに使用中の場合の、無害な拒否も確認します。
引き続き Workspace の /home/labex/project/release-desk/editor で作業します。ローカルブランチを一覧表示します。
git --no-pager branch
現在のブランチは main で、release/1.0 はすでに存在します。リンクされたワークツリーは、同じリポジトリに接続された別の作業ディレクトリです。コミットとブランチ参照を共有しつつ、チェックアウト中のブランチ、HEAD、インデックスをそれぞれ持ちます。作成しても、main ディレクトリの下書きを stash したり破棄したりはしません。
まず、保護されるケースを確認します。次のコマンドは、main is already checked out と表示され、非ゼロのステータスで失敗することを想定しています。 単独で実行してください。.. は親ディレクトリを意味するため、要求するディレクトリは editor の隣になります。
git worktree add ../busy-preview main
Git は、すでにチェックアウトされているブランチをもう一度開くことを拒否します。強制するオプションは追加しないでください。既存の登録を確認します。
git worktree list
editor が main 上にあることが示されます。修復のための reset は不要です。ここで、別の既存の保守ブランチを明示的に開きます。
git worktree add ../supported-v1 release/1.0
../supported-v1 は新しい作業ディレクトリ、release/1.0 は開く既存のブランチです。ブランチを省略すると、誤った開始点から新しいブランチを作る可能性があるため、両方の引数を残してください。
2つの実際のワークツリーを一覧表示し、保守用のものに移動します。
git worktree list
cd ../supported-v1
git branch --show-current
git status --short
release/1.0 が表示され、変更ファイルの出力はないはずです。このクリーンなインデックスは、main の未完成の作業とは別です。リンクされたワークツリーの .git は通常、共有リポジトリのメタデータを指す小さなファイルです。独立したクローンではありません。
サポート中の版の名称とダウンロード設定を読みます。
cat release.txt
cat full-guide.path
ls downloads
版は Pocket Edition 1.0 のままです。リンク設定は /downloads/harbour-guid-v1.txt ですが、実際の完全版ガイドファイルは harbour-guide-v1.txt です。リンクに e が1文字足りません。通常ファイルの形、書式、無関係な内容はすべて保持してください。チェックポイントでは、単なるフォルダーの存在ではなく、Git 本来のリンク関係と main の保持を確認します。
リンクを修正して下書きを保持する
このステップでは、バージョン管理されたリンクを1つ修正し、保守コミットを記録して、完全な旧ガイドを試します。また、元のステージ済みと未ステージの作業が別々に残っていることを確認します。
引き続き Workspace の /home/labex/project/release-desk/supported-v1 で作業します。設定ファイルには、Web サイトの絶対パス1つと改行が含まれています。printf は書式を使って値を出力します。%s はテキスト、\n は改行の追加を意味します。単一引用符は、その書式をそのまま保持します。> は、指定したファイルだけを出力された値で置き換えます。この小さな設定ファイルにだけ使ってください。
printf '%s\n' '/downloads/harbour-guide-v1.txt' > full-guide.path
ステージする前に、1行の修正を確認します。
git --no-pager diff -- full-guide.path
harbour-guid-v1.txt から harbour-guide-v1.txt への変更だけがあるはずです。そのファイルをステージし、ステージされたパッチを確認します。
git add full-guide.path
git --no-pager diff --cached -- full-guide.path
add は、このワークツリーのファイルをこのワークツリーのインデックスに書き込みます。main の下書きをステージするわけではありません。修正を記録します。-m は意味のあるメッセージを直接指定し、引用符は空白を保持します。
git commit -m "Repair the supported Harbour guide link"
保守用の履歴を確認します。--oneline はコミットごとに短い1行を表示し、--decorate はブランチとタグのラベルを表示します。
git --no-pager log --oneline --decorate
git status --short
元のサポート中のコミットのすぐ上に修正が1つあり、Explorer の改版コミットはなく、保守用ワークツリーがクリーンであるはずです。用意された supported-start タグは、元の保守用の先端を示します。変更しないでください。コミットでサポート中のブランチが進み、ローカルプレビューはそのブランチを読み取ります。この環境では、リモートへのプッシュやホスティング環境へのデプロイは扱いません。
Release Desk に切り替えます。ヘッダーの Release Desk をクリックして概要へ戻り、Open supported release を開きます。Pocket Edition 1.0、Harbour Loop、3.2 km、North Pier を確認します。
左側の Pocket Edition 1.0 と右側の2つのダウンロードリンクを探します。狭い画面では、ダウンロードパネルはリリース詳細の下にあります。
Download full guide をクリックし、ブラウザーのダウンロード一覧から実際の harbour-guide-v1.txt を開きます。North Pier の出発点、Clock Steps、古いボートハウス、Anchor Square を通る番号付きの3つの道順すべて、3.2 km の距離、最後の道とごみについての注意が含まれていなければなりません。200 の応答やファイル名だけでは、内容が完全だとは確認できません。
Download quick start をもう一度クリックし、元の短いチェックリストも引き続き使えることを確認します。All releases から開発プレビューを開き、Explorer Edition 2.0 が変わっていないことを確認します。All releases で戻ります。
Workspace に切り替え、元のディレクトリに戻ります。
cd /home/labex/project/release-desk/editor
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、同じステージ済みの写真計画の文、別に残る同じ未ステージの紫色の表紙の文、変更されていない非公開メモがあるはずです。チェックポイントでは、修正済みブランチと実際のダウンロードを、これらの保持された事実とともに確認します。リンクされたワークツリーは利用できる状態で残してください。削除は成果物の要件に含まれません。
まとめ
既存の保守ブランチを実際のリンクされたワークツリーで開き、使用中ブランチに対する保護のための拒否を確認し、元のステージ済みと未ステージの作業を乱さずに、サポート中のダウンロードを1つ修正しました。旧版、2つの実用的なダウンロード、非公開メモはそのまま残りました。
次の独立して初期化されるガイド付き実験では、もう一度編集する代わりに、開発側にある既存の独立した修正を再利用します。同じブランチと下書きの保持の判断を続けながら、cherry-pick を追加します。
