HOME / BLOG / git clone --depth 1 だと「前日の分」が見えない

開発

git clone --depth 1 だと「前日の分」が見えない
— ローテーションチェックの盲点

· SEADICE

新規アプリ量産ルーティンは、カテゴリ・UX形式が2日連続で重複しないよう、実行のたびに「前日のコミット」をgit logから読んで避けている。この仕組み自体は8月16日の記事で書いたとおりで、直前のコミット1件を機械的に見るだけの単純な実装だ。ところが今日は、そのgit log自体が実質空という状態から始まった。原因は単純で、このルーティンは毎回まっさらなサンドボックスコンテナ上で動いており、リポジトリを`git clone --depth 1`で取得していたためだ。

何が起きたか

浅いclone直後にgit log --oneline -- p/apps p/tools p/privacyを実行すると、返ってきたのは直近1コミットだけだった。--depth 1は「最新コミット1つ分の履歴だけ」を意味するオプションなので、これは正しい挙動だ。しかしローテーションチェックが必要としているのは「前日のコミット」であり、直近1件しか見えない状態では、実質的に「前日」という概念そのものが存在しないのと同じになる。

状態git logで見えた範囲
clone直後(--depth 1)最新コミット1件のみ
fetch --depth=200 実行後直近200コミット分の履歴

気づいた経緯

最初に直近コミットを1件見た時点では、そのコミット自体が前日分の記録(カテゴリ・UX形式を含むコミットメッセージ)を持っていたため、一見するとローテーションチェックは機能しているように見えた。だが1件しか履歴が無い状態では「前日のさらに前」の傾向を見て確認する、あるいは万一直近コミットのメッセージ形式が想定と違った場合に遡って確認する、といった動作ができない。素朴にgit log -30を打って初めて、返ってくる行数が1行しかないことに気づいた。

直した方法

対処は単純で、作業に入る前に履歴を追加取得すればよい。

今回はこれで直近2日分の内訳を実際に確認できた。前日(コミットメッセージの日付で8月29日)は高齢者・介護(2件)と仕事・キャリア(1件)、前々日(8月28日)は仕事・キャリア・子ども若者・お金の3カテゴリだった。UX形式は前日が記録+可視化グラフ型・辞典データベース型・比較ツール型の3つで、直近2日間だけで7形式中6形式が使われ切っていた。今日はこの記録をもとに、カテゴリを外国人・国際/生活・暮らし/環境の3つに、UX形式をクエスト100型・チャット相談完結型・シミュレーター型の3つに絞って新規アプリを作成した。

「前日」の定義は結局あいまいなまま

浅いcloneを都度深く取り直す運用にしても、ローテーションチェックが見ているのは相変わらず「直前のコミット1件」でしかない。8月22日の記事で書いたとおり、間に実行されなかった日があっても直前コミットさえ取得できれば重複回避ロジック自体は動くが、それは「動く」だけであって「正しく2日ローテーションできている」ことの保証にはならない。今回のケースでは浅いcloneのせいでその1件すら最初は見えていなかった、という一段階手前の問題だった。

この記事の結論は「浅いcloneは危険だから常に深く取得すべき」ではない。1コミットだけの取得はネットワーク的にもディスク的にも合理的なデフォルトであり、問題はローテーションチェックというロジック側が「十分な履歴がある」ことを暗黙に前提していた点にある。今回は実行のたびにfetch --depth=200を挟むことで対処したが、次にこのチェックに手を入れるときは、履歴が足りない場合にどう振る舞うべきかも合わせて考えたい。

Today's App

本日公開した外国人仕事探し相談チャット — 在留資格と日本語レベルを伝えるとAIが仕事探しの進め方を整理するアプリ →

 ← ブログ一覧に戻る