🚛 動いているFlaskアプリを5時間総点検――コード・README・Docker・Gitを「現在の仕様」に揃える方法

Last updated at 2026-07-19Posted at 2026-07-19

はじめに

Pythonを独学で学習中の現役トラックドライバーです。

物流現場で身につけた「積み残しを出さない」「出荷前に点検する」という考え方を、
Webアプリケーション開発にも取り入れています。

Python学習開始から69日目、累計148時間。

今回は、ベーカリー向け売上管理アプリ sales_data_app に新機能を追加したのではなく、
リポジトリ全体の整理・点検・不要コード削除に5時間を使いました。

対象にしたのは、コードだけではありません。

README
スクリーンショット
デモ動画
サムネイル
.gitignore
.dockerignore
旧Excel処理
未使用import
不要になった依存関係
未使用CSS
古い画面文言
Git競合記号
pytest
GitHubとの同期状態

アプリ自体は動いていました。

しかし、アプリが動いていることと、リポジトリ全体が現在の仕様と一致していることは別です。

開発を重ねるほど、過去の仕様、古い画像、不要になった設定、使われなくなったCSSなどが少しずつ残ります。

物流で例えるなら、配送は正常に完了しているものの、荷台の隅に古い資材や伝票が残っている状態です。

そこで今回は、新しい荷物を積む前に、荷台を一度総点検しました。

この記事で伝えたいのは、単なるファイル整理の手順ではありません。

動いているアプリでも、コード・依存関係・画面・説明資料・Docker・Gitの状態が、現在の仕様と一致しているとは限らない

ということです。

この記事で分かること

この記事では、次の内容を扱います。

Flaskリポジトリ全体を点検する考え方
削除候補を安全に確認する順序
.gitignoreと.dockerignoreの役割の違い
未使用import・依存関係・CSSの探し方
grepで結果が出なかった場合の考え方
Git競合記号の検索で誤検出した理由
目的の異なる変更を混ぜないコミット判断
pytestとworking tree cleanまで確認する理由
別のプロジェクトでも使える総点検チェックリスト

この記事は長めです。

最初から順番に読むほか、気になる見出しだけ読む使い方や、
記事後半の「リポジトリ総点検チェックリスト」を実作業で使うことも想定しています。

対象アプリ

sales_data_appは、ベーカリーの商品登録、日次売上入力、売上分析、Gemini APIによる経営アドバイスをまとめたWebアプリケーションです。

主な技術構成は次のとおりです。

Python 3.12
Flask
PostgreSQL
SQLAlchemy
Flask-Migrate / Alembic
Docker / Docker Compose
Gunicorn
Render
pytest
GitHub Actions
Gemini API

アプリでは、次のような業務フローを扱っています。

商品メニューと価格を登録する
        ↓
本日の販売個数を入力・更新する
        ↓
売上ランキングとグラフを確認する
        ↓
Geminiから経営アドバイスを受ける

今回の総点検を「5つの層」で考える

今回の作業を振り返ると、リポジトリの点検対象は大きく5つの層に分けられました。

① 実行コード
   未使用import、旧処理、古い設定、未使用CSS

② 依存関係
   requirements.txtに残っている不要なライブラリ

③ UI・説明資料
   HTMLの文言、README、スクリーンショット、デモ素材

④ 配送範囲
   .gitignore、.dockerignore

⑤ 出荷状態
   pytest、git diff、git status、GitHubとの同期

この5層に分けると、単に「不要ファイルを探す」よりも点検範囲が明確になります。

リポジトリの総点検とは、不要ファイルを消すだけの作業ではありません。

現在の仕様と、コード・依存関係・画面・説明資料・出荷状態を一致させる作業

だと考えています。

今回行った作業

5時間で行った主な作業は次のとおりです。

デモ動画・サムネイル・スクリーンショットの整理
README内の画像パス修正
最新画面のスクリーンショット撮影
.gitignoreの整理
.dockerignoreの整理
旧Excel処理の削除
未使用importの削除
openpyxl依存関係の削除
未使用CSSの削除
古い画面タイトルの修正
旧仕様の残存検索
Git競合記号の検索
変更目的ごとのコミット
pytest実行
GitHubとの同期確認
2つのREADMEへの実績反映

ここから、実際に行った順番で記録します。

1. 画像と動画を用途別に整理する

最初に、リポジトリ内のデモ素材を整理しました。

整理後の構成は次のとおりです。

sales_data_app/
├── demo_mp4/
├── demo_thumbnail/
├── screenshot/
├── static/
├── templates/
└── README.md

用途も明確に分けました。

demo_mp4/
└── デモ動画

demo_thumbnail/
└── YouTube用サムネイル

screenshot/
└── README掲載用スクリーンショット

以前は、動画や画像がルート直下など複数の場所に混在していました。

アプリの動作には直接影響しません。

しかし、第三者がリポジトリを見たときに、次の判断が難しくなります。

この画像は何に使うのか
現在も必要なファイルなのか
アプリの実行に必要なのか
説明用の資料なのか

フォルダ名と配置を整理することで、ファイルを開かなくても役割を推測しやすくなります。

フォルダ整理は、単なる見た目の問題ではありません。

ファイルの役割を名前と配置で伝える、
リポジトリ内の情報設計でもあります。

ファイル移動後はREADMEのパスも修正する

ファイルを別フォルダへ移動すると、README内の参照先も変わります。

たとえば、スクリーンショットをscreenshotフォルダへ移した場合は、README側も現在の配置に合わせます。

![商品マスタ登録画面](screenshot/screen01.jpg)

ファイル整理だけ行い、READMEのパスを修正し忘れると、GitHub上で画像が表示されなくなります。

そのため、今回は次の順番で確認しました。

ファイルを移動する
        ↓
README内の参照先を修正する
        ↓
GitHub上で画像が表示されるか確認する

2. READMEと最新画面を一致させる

READMEに掲載していたスクリーンショットの一部は、現在の画面と一致していませんでした。

そのため、最新版を起動して画面を撮影し直しました。

更新した主な画面は次のとおりです。

商品マスタ登録画面
メニュー登録完了画面
日次売上入力画面
売上分析ダッシュボード

READMEのスクリーンショットは、単なる飾りではありません。

第三者がリポジトリを開いたとき、コードより先に画面画像を見る場合があります。

画像が古いままだと、現在は改善済みのUIであっても、古い状態のアプリとして伝わってしまいます。

HTML内に残っていた古いタイトル

画面を確認する中で、HTML内に古いタイトルが残っていることも分かりました。

修正前は次の表現でした。

<title>売上集計完了</title>

しかし、現在の画面の役割は売上集計ではなく、商品メニューの登録完了です。

そこで、次のように修正しました。

<title>メニュー登録完了</title>

ブラウザのタブに表示されるtitleも、利用者へ伝わる仕様の一部です。

画面内の見出しだけ直しても、タブのタイトルが古ければ、処理内容と表示が一致しません。

アプリが正常に動作していても、古い文言が残っていれば、利用者やコードを読む人に誤解を与える可能性があります。

UIの文言も、コードと同じように現在の仕様へ合わせる必要があります。

3. `.gitignore`を現在の開発環境へ合わせる

次に、Gitで追跡する必要がないファイルを見直しました。

整理後の.gitignoreは次のようになりました。

# Python系
.venv/
__pycache__/
*.pyc
.pytest_cache/

# 現場の生データ・機密ファイル
過去売上高/
*.xlsx
*.db
.env

# その他不要ファイル
*.bak
sales_data_app_android_demo.mp4

仮想環境・キャッシュを追跡しない

.venv/
__pycache__/
*.pyc
.pytest_cache/

これらは開発環境ごとに生成されます。

GitHubへ登録しなくても、必要に応じて各環境で再生成できます。

機密情報を追跡しない

.env

.envにはGemini APIキーなどの機密情報が含まれる可能性があります。

公開リポジトリへ誤ってpushしないため、明示的に除外します。

ローカルデータを追跡しない

*.db
*.xlsx
過去売上高/

本番環境ではPostgreSQLを使用しています。

ローカル開発用のSQLiteファイルや、過去のExcel資料をGitHubへ含める必要はありません。

ただし、ここで注意したいのは、

古そうなファイル
=
すぐ削除してよいファイル

ではないことです。

今回もlocal.dbについては、設定ファイルから参照されていることを確認しました。

そのため、リポジトリから追跡しない対象にはしましたが、ローカル環境からすぐ物理削除する判断はしていません。

4. `.dockerignore`で本番へ積む荷物を決める

Gitで追跡しないファイルと、Dockerのビルド対象へ送らないファイルは、目的が異なります。

そのため、.dockerignoreも別に整理しました。

# Git
.git
.gitignore

# 環境変数・仮想環境
.env
.venv/
venv/

# Python・テストキャッシュ
__pycache__/
*.pyc
.pytest_cache/

# ローカルデータ・旧資料
*.db
*.xlsx
過去売上高/
*.bak

# 開発・説明用ファイル
README.md
test_prompts.py
demo_mp4/
demo_thumbnail/
screenshot/

# OS・ログ
*.log
.DS_Store

README、スクリーンショット、デモ動画、テストファイルは、GitHub上では意味があります。

しかし、今回の本番実行用Dockerイメージには不要です。

.gitignoreと.dockerignoreは目的が異なります。

.gitignore
Gitで追跡しないファイルを決める
.dockerignore
Dockerのビルド対象へ送らないファイルを決める

物流で例えるなら、次の違いです。

倉庫に保管しておく資料
≠
配送車へ積み込む荷物

GitHubには、開発記録や説明資料を残す価値があります。

一方、Dockerにはアプリの実行に必要なファイルだけを積みます。

GitHubへ残すか、Dockerへ積むかを2つの質問で判断する

ファイルを分類するときは、次の2つを考えると分かりやすくなります。

① GitHubへ残す価値があるか
② 本番実行時に必要か

ファイル	GitHub	Docker	理由
アプリ本体	必要	必要	実行に必要
HTML・CSS	必要	必要	画面表示に必要
README	必要	不要	説明資料
スクリーンショット	必要	不要	GitHub上の説明用
デモ動画	必要	不要	実行には不要
テストファイル	必要	今回は不要	CI・開発用
`.env`	不要	不要	機密情報
`.venv`	不要	不要	環境ごとに再生成
SQLiteファイル	不要	不要	ローカルデータ

この分類なら、単に設定例をコピーするのではなく、自分のプロジェクトに合わせて判断できます。

5. 旧Excel処理の残骸を探す

このアプリは、開発初期にExcelを利用していました。

その後、PostgreSQL中心の構成へ移行しましたが、旧仕様の一部が残っていました。

今回見つかった主なものは次のとおりです。

`config.py`に残っていた旧フォルダ設定

PAST_FOLDER_NAME = "過去売上高"
PAST_FOLDER = os.path.join(BASE_DIR, PAST_FOLDER_NAME)

`app.py`に残っていたフォルダ作成処理

os.makedirs(config.PAST_FOLDER, exist_ok=True)

未使用になっていたimport

from flask import send_file
from google.genai import types

不要になった依存関係

openpyxl

現在のアプリでは、売上データをPostgreSQLへ保存しています。

Excelファイルを生成・送信する処理は使っていません。

そこで、参照箇所を確認したうえで削除しました。

6. 削除候補を見つけても、すぐ削除しない

今回の点検で重要だったのは、古そうなコードを見つけた瞬間に削除しなかったことです。

削除候補は、次の順番で確認しました。

名前で検索する
        ↓
どこから参照されているか確認する
        ↓
現在の仕様で必要か確認する
        ↓
削除する
        ↓
同じ名前でもう一度検索する
        ↓
テストする

たとえば、openpyxlという文字列を見つけた場合でも、requirements.txtからすぐ消すのではなく、コード内で本当に使われていないか確認します。

同様に、設定名やCSSクラスも、定義だけでなく参照側を探します。

「古そう」「使っていなさそう」という感覚だけで削除すると、別ファイルから参照されている処理を壊す可能性があります。

削除前と削除後の検索を1セットにすると、安全性を上げられます。

7. 変更結果は23行削除、2行修正

旧Excel処理、未使用import、不要依存関係、未使用CSS、古い画面タイトルを整理した結果、差分は次のようになりました。

app.py                 | 10 +---------
config.py              |  4 ----
requirements.txt       |  1 -
static/style.css       |  8 --------
templates/success.html |  2 +-
5 files changed, 2 insertions(+), 23 deletions(-)

今回は、新しいコードを大量に追加したわけではありません。

現在の仕様では不要になった23行を削除しました。

コード量が増えることだけが開発ではありません。

現在使われていない処理を、根拠を持って減らすことも改善です。

コードが少なくなれば必ず良いわけではありません。

しかし、不要なコードが減ることで、次の効果が期待できます。

現在の処理を理解しやすくなる
旧仕様を誤って再利用する可能性が減る
依存関係の役割が明確になる
将来の修正対象が減る
READMEと実装の不一致を防ぎやすくなる

8. 未使用CSSを検索して削除する

HTMLやJavaScriptから使われていないCSSが残っていないか、grepで確認しました。

grep -Rni "ai-loading" \
  templates \
  static \
  app.py

最初の検索では、CSSファイル内の定義だけが見つかりました。

static/style.css:680:.input-page .ai-loading {

テンプレートやJavaScriptからは使用されていませんでした。

そのため、セレクタ名だけではなく、CSSブロック全体を削除しました。

.input-page .ai-loading {
    /* 未使用だったスタイル */
}

削除後、同じ検索をもう一度実行しました。

grep -Rni "ai-loading" \
  templates \
  static \
  app.py

結果は0件でした。

何も表示されない

同様に、現在のダッシュボードでは使われていない古い.btn-backのスタイルも削除しました。

CSSは定義だけ見つかっても、使用中とは限らない

CSSクラスがファイル内に存在することと、画面から実際に使われていることは別です。

確認するときは、次の両方を見ます。

CSS側に定義があるか
HTML・JavaScript側から参照されているか

CSS定義だけが残り、どこからも参照されていない場合は、削除候補になります。

ただし、JavaScriptで動的に付与されるクラスもあるため、HTMLだけを見て判断しないよう注意が必要です。

9. `grep`の赤いバツは、必ずしも異常ではなかった

古い文言やクラス名を検索したところ、結果は何も表示されませんでした。

しかし、ターミナルには赤いバツが表示されました。

最初は、コマンドが失敗したのではないかと思いました。

調べると、grepの終了ステータスは次の意味を持ちます。

0: 一致する行が見つかった
1: 一致する行が見つからなかった
2以上: コマンド自体のエラー

今回は、探していた古い記述が見つからなかったため、終了コード1になっていました。

つまり、今回の目的では期待した結果です。

一致なし
=
旧仕様の残骸なし

ターミナルの記号や色だけで成功・失敗を判断せず、
コマンドの終了コードが何を意味しているか確認する必要があります。

検索結果0件も立派な確認結果

検索は、問題を見つけるためだけに使うものではありません。

「存在しないこと」を確認するためにも使えます。

たとえば、削除後に同じ名前を検索し、0件になれば、

削除対象の名前が残っていない

ことを確認できます。

この場合、何も表示されないこと自体が結果です。

ここまでに登場したコマンドを、すべて暗記する必要はありません。

大切なのは、

何を探すためのコマンドなのか
結果が出た場合と出なかった場合をどう判断するのか
必要なときに履歴や記事から再利用できること

です。

次に登場する正規表現も、細かい記号をすべて暗記するのではなく、
今回は「Gitの競合記号だけを行単位で探す条件」と考えれば大丈夫です。

10. Git競合記号の検索でCSSを大量検出した

次に、Gitの競合記号が残っていないか確認しました。

Gitで競合が発生すると、ファイル内に次のような記号が入ることがあります。

<<<<<<< HEAD
現在の内容
=======
別の変更内容
>>>>>>> branch-name

最初に実行した検索は次のとおりです。

grep -RniE \
  '<<<<<<<|=======|>>>>>>>' \
  --exclude-dir=.git \
  --exclude-dir=.venv \
  --exclude-dir=__pycache__ \
  --exclude-dir=.pytest_cache \
  .

すると、static/style.cssの区切りコメントを大量に検出しました。

/* ========================================
見出し
======================================== */

検索条件の=======が、CSSの装飾用イコールにも一致したためです。

行頭へ限定しても、まだ誤検出した

次に、行頭へ限定しました。

grep -RniE \
  '^(<<<<<<< |=======|>>>>>>> )' \
  --exclude-dir=.git \
  --exclude-dir=.venv \
  --exclude-dir=__pycache__ \
  --exclude-dir=.pytest_cache \
  .

しかし、CSSの区切り線もイコールから始まっていました。

そのため、まだ大量に検出されました。

Git競合記号の形式だけへ絞る

最終的に、行頭と行末を含め、Git競合記号の形式だけへ条件を絞りました。

grep -RniE \
  '^(<<<<<<< .+|=======$|>>>>>>> .+)$' \
  --exclude-dir=.git \
  --exclude-dir=.venv \
  --exclude-dir=__pycache__ \
  --exclude-dir=.pytest_cache \
  .

結果は0件でした。

何も表示されない

これで、Git競合記号が残っていないことを確認できました。

検索結果が多いからといって、問題が多いとは限らない

今回の経験から、次のことが分かりました。

検索結果が多い
=
問題が多い

とは限りません。

検索条件が広すぎると、正常なコードやコメントまで拾います。

今回の場合は、

Git競合記号を探したい
        ↓
=======を含む行を検索
        ↓
CSSの装飾用イコールにも一致

という状態でした。

検索結果を見る前に、

この検索条件は、問題以外の何に一致する可能性があるか

を考える必要があります。

11. 検索コマンドは「発見」より「仮説検証」に使う

今回のgrepは、単にファイル内の文字を探すためだけに使ったわけではありません。

次のような仮説を確認するために使いました。

旧Excel処理がまだ残っているのではないか
未使用CSSが残っているのではないか
古い画面文言が残っているのではないか
Git競合記号が残っているのではないか

検索結果を見て、必要に応じて条件を修正します。

仮説を立てる
        ↓
検索する
        ↓
結果を確認する
        ↓
誤検出か本当の問題か判断する
        ↓
検索条件またはコードを修正する
        ↓
再検索する

この流れなら、検索コマンドを暗記することよりも、何を確かめたいかが中心になります。

12. 関連する変更はまとめ、別目的が混ざる前にコミットする

今回変更したファイルは次の5つです。

app.py
config.py
requirements.txt
static/style.css
templates/success.html

ファイルは複数ありますが、変更内容はすべて次の1つの目的にまとまっていました。

旧仕様と未使用コードの整理

そのため、次のコミットメッセージで記録しました。

git commit -m "旧Excel処理と未使用コードを整理"

コミットを細かく分けすぎても、まとめすぎても読みにくい

1行変更するたびにコミットすると、作業の流れが細かく分断されます。

一方で、目的の異なる変更を大量にまとめると、あとから差分を理解しにくくなります。

今回は、次の基準でコミットしました。

関連する変更はまとめる
別の目的が混ざる直前でコミットする

物流で例えるなら、

同じ届け先の荷物
        ↓
一緒に積む

別の届け先の荷物
        ↓
混ざる前に出荷する

という感覚です。

コミット前に確認したこと

コミット前には、次の2つを確認しました。

git status
git diff --stat

git statusでは、変更されたファイルを確認します。

git diff --statでは、変更量の概要を確認します。

今回の結果は次のとおりでした。

app.py                 | 10 +---------
config.py              |  4 ----
requirements.txt       |  1 -
static/style.css       |  8 --------
templates/success.html |  2 +-
5 files changed, 2 insertions(+), 23 deletions(-)

この段階で、関係のないファイルが混ざっていないことを確認しました。

13. 最終テストを実行する

変更をコミットしてpushしたあと、pytestを実行しました。

pytest

結果は次のとおりです。

================================================== test session starts ==================================================
platform linux -- Python 3.12.3, pytest-9.1.1, pluggy-1.6.0
rootdir: /home/tosane/sales_data_app
plugins: anyio-4.13.0
collected 3 items

test_prompts.py ...                                                                                                [100%]

=================================================== 3 passed in 0.20s ===================================================

3件すべて成功しました。

3 passed in 0.20s

ただし、現在のpytestはプロンプト生成ロジックを中心とした3件です。

そのため、

pytestが通った
=
アプリ全体のすべてが保証された

という意味ではありません。

テスト対象の範囲を理解したうえで、検索・差分確認・画面確認も組み合わせています。

テストが存在することと、重要な処理が十分に守られていることは別です。

どの処理がテスト対象なのかを把握する必要があります。

14. `working tree clean`まで確認する

最後にGitの状態を確認しました。

git status

結果は次のとおりです。

On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

これで、次の状態を確認できました。

未コミットの変更がない
GitHubとmainブランチが同期している
作業途中のファイルが残っていない

コードを直しただけでは、作業完了ではない

今回、作業完了を次のように定義しました。

コードを修正した
        ↓
差分を確認した
        ↓
テストが通った
        ↓
コミットした
        ↓
GitHubへpushした
        ↓
GitHubと同期した
        ↓
未処理の変更が残っていない

つまり、

コードを直した
≠
作業が終わった

です。

working tree cleanは、単なる表示ではありません。

次の作業を、前回の未処理変更と混ぜずに始められる状態を示しています。

物流で言えば、配送が終わっただけでなく、帰庫後に荷台を確認し、積み残しがないことまで確かめた状態です。

15. READMEにも今日の実績を反映する

コードとリポジトリの整理が終わったあと、次の2つのREADMEも更新しました。

sales_data_appのREADME
GitHubプロフィール用README

`sales_data_app`側のREADME

更新履歴へ、次の内容を追加しました。

デモ動画・サムネイル・スクリーンショットの整理
README内の画像パス修正
.gitignoreの整理
.dockerignoreの整理
旧Excel処理の削除
未使用import・依存関係・CSSの削除
古い画面タイトルの修正
pytest 3件成功
Git作業ツリーcleanの確認

GitHubプロフィール用README

2026年7月19日のマイルストーンとして、今回の総点検を記録しました。

学習時間も更新しました。

累計143時間
        ↓
累計148時間

READMEの変更は、次のコミットメッセージで記録しました。

git commit -m "READMEにリポジトリ総点検と学習148時間を反映"

16. 5時間の作業結果

今回の結果をまとめると、次のとおりです。

作業時間              5時間
累計学習時間          148時間
コード変更            5ファイル
差分                  23行削除、2行修正
旧仕様の検索          0件
Git競合記号           0件
pytest                3 passed
GitHubとの差分         なし
最終状態              working tree clean

新機能の追加はありません。

しかし、次の要素を現在の仕様へ合わせられました。

コード
依存関係
HTMLの文言
CSS
README
スクリーンショット
フォルダ構成
.gitignore
.dockerignore
Gitの状態

今回学んだこと

1. 動いているアプリにも古い部品は残る

アプリが正常に動いていても、以前の構成で必要だったコードや依存関係が残ることがあります。

今回の例では、次の変化がありました。

Excel中心の構成
        ↓
PostgreSQL中心へ移行
        ↓
旧Excelフォルダ設定やopenpyxlが不要になる

機能追加だけを続けると、過去の仕様が静かに残ります。

そのため、現在の構成と一致しているか、定期的に確認する必要があります。

2. READMEや画像もソフトウェアの一部

コードが最新でも、READMEの画像や説明が古ければ、第三者には古い状態として伝わります。

公開リポジトリでは、次のすべてが成果物です。

コード
README
スクリーンショット
デモ動画
フォルダ構成
コミット履歴

READMEは、コードの外側にある付属品ではありません。

利用者や採用担当者、別の開発者が、プロジェクトを理解するための入口です。

3. GitHubへ置くものとDockerへ積むものは異なる

READMEやテストファイルはGitHubには必要です。

しかし、本番Dockerイメージには必要ない場合があります。

GitHub
└── 開発記録・テスト・説明資料も保管する

Docker
└── 本番実行に必要なファイルを積む

.gitignoreと.dockerignoreを同じ内容にするのではなく、それぞれの目的で判断する必要があります。

4. 削除には根拠が必要

未使用に見えるコードを、勢いだけで削除するのは危険です。

今回は、次の順番で確認しました。

検索
↓
参照元の確認
↓
現在の仕様との比較
↓
削除
↓
再検索
↓
テスト

削除とは、単にコードを減らす作業ではありません。

「現在は不要である」と説明できる状態にしてから行う作業です。

5. 検索結果0件も重要な確認結果

旧仕様が残っていないことを確認する場合、grepの一致なしは期待した結果になります。

問題を見つける検索
一致あり → 確認対象がある

残存していないことを確かめる検索
一致なし → 期待した状態

検索結果の意味は、検索した目的によって変わります。

6. 検索条件は誤検出の可能性まで考える

=======を検索すると、Git競合記号だけでなく、CSSの区切り線にも一致しました。

検索結果が多い
=
問題が多い

ではありません。

検索条件が広すぎる可能性もあります。

検索結果だけで判断せず、なぜ一致したのかを見る必要があります。

7. コミットは「変更ファイル数」ではなく「変更目的」で分ける

今回の変更は5ファイルにまたがりました。

しかし、目的はすべて同じでした。

旧仕様と未使用コードの整理

そのため、1つのコミットとしてまとめました。

コミットを分ける基準は、

何ファイル変更したか

より、

何のために変更したか

の方が理解しやすいと感じました。

8. `working tree clean`は次の作業への出発条件

未コミットの変更が残ったまま次の作業を始めると、別目的の変更が混ざる可能性があります。

今回の変更
+
次回の変更
=
コミットの目的が分かりにくくなる

working tree cleanまで確認しておけば、次の作業を空の荷台から始められます。

別のプロジェクトでも使えるリポジトリ総点検チェックリスト

今回の作業を、自分以外のプロジェクトでも再利用できる形にまとめます。

実行コード

未使用importが残っていないか
廃止した仕様の設定が残っていないか
使われていない関数や処理が残っていないか
旧フォルダや旧ファイル名への参照が残っていないか
未使用CSSやクラスが残っていないか
JavaScriptから動的に使われるクラスではないか確認したか

依存関係

現在使っていないライブラリが残っていないか
削除前にコード内の参照箇所を検索したか
直接使用していなくても別ライブラリが必要としていないか
依存関係削除後にアプリやテストが動くか確認したか

README・画面

READMEの説明と現在の実装が一致しているか
スクリーンショットは最新版か
画像パスが現在のフォルダ構成と一致しているか
デモ動画の説明が現在の画面と矛盾していないか
古い画面文言やtitleが残っていないか
現在使っていない機能がREADMEに書かれていないか

ファイル構成

動画・画像・資料が用途別に整理されているか
ルート直下へ不要なファイルが散らばっていないか
バックアップファイルが残っていないか
ファイル名だけで用途を推測できるか

Git

.gitignoreで機密情報を除外しているか
仮想環境やキャッシュを除外しているか
ローカルDBや生データを除外しているか
git statusで変更対象を確認したか
git diffまたはgit diff --statで差分を確認したか
目的の異なる変更が混ざっていないか
Git競合記号が残っていないか
GitHubへpushしたか
working tree cleanになっているか

Docker

.dockerignoreで.gitを除外しているか
.envをビルド対象から除外しているか
仮想環境やキャッシュを除外しているか
ローカルDBやExcel資料を除外しているか
README・画像・動画など本番不要資料を除外しているか
GitHubへ残すファイルとDockerへ積むファイルを区別しているか

最終確認

削除した名前を再検索したか
検索結果が誤検出ではないか確認したか
テストが通ったか
テスト対象の範囲を理解しているか
必要な画面を目視確認したか
READMEへ今回の変更を反映したか
GitHubとローカルが同期しているか

おわりに

今回の5時間では、新しい機能を追加していません。

それでも、次の状態まで整えることができました。

現在の仕様とコードが一致している
古い依存関係が残っていない
READMEと最新画面が一致している
動画や画像の役割が分かりやすい
GitHubへ残すものが整理されている
本番Dockerへ不要な資料を積まない
テストが通っている
GitHubと同期している
作業ツリーがcleanである

物流現場では、荷物を積むだけでなく、次の点も確認します。

不要な荷物が混ざっていないか
積載場所は分かりやすいか
荷物と伝票が一致しているか
配送後に積み残しがないか
次の運行を空の荷台から始められるか

ソフトウェア開発でも同じでした。

コードを追加する
        ↓
不要なコードを降ろす
        ↓
説明資料を現在の状態へ合わせる
        ↓
本番へ積むファイルを整理する
        ↓
テストする
        ↓
GitHubへ出荷する
        ↓
working tree cleanを確認する

今回の総点検で一番強く感じたのは、次のことです。

リポジトリの総点検とは、不要ファイルを消す作業ではない。
現在の仕様と、コード・依存関係・画面・説明資料・出荷状態を一致させる作業である。

新機能を積む前に、現在の荷台を点検する。

今回の5時間は、次の開発を安全に始めるための整備時間になりました。