仮想空間の日常

▲ 【Day 28】git add -p で必要な行だけを綺麗にコミットする部分ステージング技 👨‍🏫 皆さん、こんにちは！ 本講座の専任講師です。 前回のDay 27では、巨大なC#ソリューションでの再ビルド待ちを完全ゼロにする神機能 「git worktree」 の内部構造と2画面並行デバッグの極意を学びました。 そして本日のDay 28は、プロの現場で毎日のように使われる超実践テクニック—— 【git add -p で必要な行だけを綺麗にコミットする部分ステージング技】 を徹底解説します！ 「C#のバグ調査や新機能開発の際、変数の値を確認するためにコードの途中に Console.WriteLine を差し込んだり、一時的なハードコード（テスト用の固定値やフラグ）を書き込むことはよくありますよね」 「しかし、いざコミットしようとしたとき、そのデバッグ行を手動で1行ずつ削除したりコメントアウトして、再度ビルド確認してからコミットしていませんか？ あるいは、削除し忘れたデバッグログがそのまま本番リポジトリにコミットされ、Pull Requestのレビューで『不要なデバッグ出力が残っていますよ』と指摘されて恥ずかしい思いをしたことはありませんか？」 かつてのSubversion (SVN) では「ファイル単位」でしかコミット対象を選択できなかったため、そうした苦労は避けられませんでした。 しかしGitには、 1つのファイル内にある変更箇所を行単位（Hunk：ハンク）で自由自在に選別し、必要な行だけをインデックス（ステージング）に載せる『git add -p (patch)』 という強力無比な機能が備わっています！ ローカルのデバッグ用ログを残したまま、本番用修正コードだけを100%美しくコミットするプロの極意を、コマンドラインとTortoiseGit GUIの両面から完全マスターしましょう！ ...

▲ Day 30: Git管理すべきファイルとVolumeに逃がすべきデータの境界線 🐳 「Dockerプロジェクト内のファイル、何でもGitにコミットしていませんか？」 前回のDay 29では、ホストPCとコンテナを直結してC#のホットリロードを実現する「バインドマウント（Bind Mount）」を学びました。 コンテナ環境でのデータ永続化（Named Volume）と高速開発（Bind Mount）の両輪を手に入れた開発チームが、次に必ず直面するのが 「プロジェクト内のどのファイルをGitで管理し、何をVolumeやローカルに逃がすべきか？」という境界線の問題 です。 昔のオンプレミス現場では、ファイルサーバーの共有フォルダにソースコード、SQL Serverの .mdf ファイル、設定ファイル、果てはログまで何でも放り込み、誰かが上書きしてDBが破損するなどの地獄絵図が日常茶飯事でした。 もしこの悪習をそのまま現代のGit×Docker環境に持ち込み、 巨大なデータベースファイルをGitにコミットしてしまうと、リポジトリが数十GBに膨れ上がり、チーム全員のPCでクローン不能になる壊滅的事故 を引き起こします。 本講義は第6部「データの永続化とボリューム」の総決算として、 「コード（Git）」「構成（Git/.env）」「データ（Volume）」の3層分離原則 と、事故を未然に防ぐ現場ルールを完全解説します！ INDEX 本日の講義カリキュラム 第1章: 共有フォルダ破綻の歴史に学ぶ 〜なぜ「何でも詰め込み」は失敗するのか？〜 第2章: 現代コンテナ開発における「...

▲ 【Day 27】git worktree で再ビルドなしの超高速ブランチ並行開発 👨‍🏫 皆さん、こんにちは！ 本講座の専任講師です。 前回のDay 26では、第5部の集大成として「AIエージェントを活用したケーススタディ自動実行（Issue-to-PR）」を学び、現代の自律型コーディング環境とGitの強力な連携をマスターしました。 そして本日のDay 27より、いよいよ 【第6部: プロの調査・保守・作業効率化テクニック】 がスタートします！ 第1弾のテーマは、チーム開発や現場で活躍する全エンジニアに知ってほしいGitの神機能—— 【git worktree で再ビルドなしの超高速ブランチ並行開発】 です！ 「新機能の開発に没頭している最中、突然本番環境で緊急障害が発生して調査を頼まれた……。ブランチを切り替えたら、Visual Studioが巨大なC#ソリューション全体をゼロから再ビルドし始め、NuGetパッケージの再復元で10分以上待たされた」 「調査が終わって元のブランチに戻ってきたら、またしても全件再ビルドで待ち時間……。開いていたタブやブレークポイントも消えて集中力が完全に削がれた」 こうした苦い経験は、エンジニアなら誰しも一度はあるはずです。 かつてのSubversion (SVN) では別フォルダにチェックアウトして複数開くことができましたが、Gitでも完全に別のフォルダへ別ブランチを即時展開し、Visual Studioを2つ同時に開いて並行デバッグできる仕組みが存在します。それが git worktree です！ リポジトリを丸ごと別cloneする必要はありません。コミット履歴やローカルブランチは完全に共有されたまま、ワーキングディレクトリとビルド生成物（bin/obj）だけを物理的に分離できます。 本日は、この git worktre...

▲ Day 29: バインドマウント（Bind Mount）によるソースコード即時反映（ホットリロード） 🐳 「C#コードを1行直すたびに docker compose build するの！？ 待ち時間が長すぎて開発にならないよ！」 前回のDay 28では、SQL ServerのDBデータを安全に保護する「Named Volume（名前付きボリューム）」を学びました。 しかし、日々のアプリケーション開発現場で同じようにボリュームを扱おうとすると、多くのエンジニアが大きな壁にぶつかります。 「コードを修正するたびに、毎回イメージの再ビルド（ docker compose up --build ）を待たなければいけないのか？」 答えはもちろん NO です！ Dockerには、ホストPC上のソースコードフォルダをコンテナ内に直接パイプで繋ぐ 「バインドマウント（Bind Mount）」 という強力な仕組みが用意されています。 さらにC#の dotnet watch コマンドと組み合わせることで、 「ホストのVisual StudioやVS Codeでコードを保存（Ctrl+S）した瞬間、コンテナ内のアプリがミリ秒で自動更新されるホットリロード環境」 が実現します！ 本講義では、バインドマウントの原理、 docker-compose.yml の設定法、そしてWSL2環境で多くの人がハマる「変更検知トラブル」の完全解決策までを徹底解説します！ INDEX 本日の講義カリキュラム 第1章: バインドマウント（Bind Mount）の基本...