仮想空間の日常

👨‍🏫 皆さん、こんにちは！ 本講座の専任講師です。 ITエンジニア歴30年以上の皆さん、Subversion (SVN) ではコミットするたびに「リビジョン 101, 102, 103...」と綺麗な連番が増えていくのが当たり前でしたよね。 Gitを初めて触ったとき、 「e4f1a23b9... なんて40文字の暗号文字列、一体誰が覚えるんだ！？」 と強烈な拒否感を覚えた方も多いのではないでしょうか。 本日は第9回として、 「なぜGitは連番ではなくハッシュなのか？」 という根本理由を解き明かし、膨大なコミット履歴から目的の変更を瞬時に見つけ出す実践的なログ閲覧術を伝授します！ ① 導入・本日の達成目標 長年VSSやSVNを使ってきたエンジニアにとって、リビジョン番号（r101など）は「プロジェクトの進行度」を示す直感的な目印でした。 しかしGitの世界では、コミットの識別子はすべて 「40文字の16進数ハッシュ値」 で管理されます。 本日の講義でマスターするゴールは以下の3つです！ なぜ分散環境では連番リビジョンが破綻するのか 、コミットハッシュ（SHA-1/256）の必然性を理解する。 git log --oneline --graph で歴史の分岐と合流を瞬時に読み解く。 TortoiseGitのログダイアログ と 4大AIエージェント を駆使して、過去のC#変更履歴を自在に検索・分析する。 ② 【根本理解】SVNリビジョン番号 vs Gitコミットハッシュの決定的違い SVNの「リビジョン番号」とGitの「コミットハッシュ」には、単なる表記の違いを超えた 思想とアーキテクチャの根本的な違い があります。 ...

▲ Day 08: Visual Studio 2022 × Docker / 右クリックとF5キーで始めるLinuxコンテナ開発 🐳 皆さん、こんにちは！ Docker/コンテナ実践講座の専任講師です。 前回のDay 07では、 .wslconfig を用いたリソース制御やディスク容量管理を行い、Windowsマシンをサクサク快適に保つインフラ設定をマスターしました。 いよいよ本日からは、 「C#エンジニアの主戦場であるVisual Studio 2022」 にDockerを完全融合させます！ かつてリモート仮想マシン（VM）に msvsmon を仕掛け、ファイアウォールと格闘しながらデバッグしていたベテランの皆さん、 「F5キーを押すだけで本物のLinuxコンテナ内でブレークポイントが止まる」 現代の圧倒的開発体験をぜひ体感してください！ ① 導入・本日の達成目標 多くのエンジニアが「Dockerを使うには、まず複雑なDockerfileの構文を全部暗記して、黒い画面（CLI）からコマンドを打ち込まなければならない」と考えがちです。 しかし、 Visual Studio 2022のコンテナ開発ツールを使えば、マウス操作わずか数クリックで業界標準のマルチステージDockerfileが自動生成 され、即座にコンテナ実行・デバッグを開始できます。 本日の講義を終える頃には、以下の3つの目標を完全にクリアできるようになります。 仮想マシンのリモートデバッグとVS2022コンテナデバッグの決定的違い を理解し、開発生産性を10倍に高める。 既存のC# / ASP.NET Coreプロジェクトへ「Dockerサポート」を正しく追加 し、自動生成される設定ファイル（ Dockerfile , .dockerignore ）をGit管理する。 ...

▲ Day 07: 変更の記録とステージング（add / commit）の作法 👨‍🏫 専任講師からのメッセージ 受講生の皆様、お疲れ様です！ 第7回講義へようこそ。 VSSやSVNなどの集中型バージョン管理システムに長年慣れ親しんだベテランエンジニアの方から、最も頻繁に寄せられる疑問がこれです： 「SVNならファイルを保存してコミットボタンを押すだけだったのに、なぜGitはわざわざ『git add（ステージング）』と『git commit（コミット）』の2段階に分かれているのか？」 実はこの「ステージング」こそが、 複数機能の混在を防ぎ、後から安全に取り消せる高品質なコードベースを保つ最大の武器 なのです。本日は「1機能1コミットの鉄則」と「AIエージェントを活用した美しいコミットメッセージ自動生成」を完全マスターしましょう！ ① なぜ2段階必要なのか？ ステージング（add）の真意 集中型バージョン管理（SVN / VSS）では、作業ディレクトリの変更がそのまま中央サーバーに一括コミットされていました。そのため、「ユーザー一覧機能を作っていたはずが、途中で見つけたバグの修正やログの追加もついでに全部まとめてコミットしてしまった」という事態が頻発していました。 Gitでは、変更されたファイル群の中から 「今回のコミットに含めたい変更だけを選択してカゴに入れる」 作業エリアが用意されています。これが 「ステージングエリア（インデックス）」 です。 ▲ 【図解①】ステージング（git add）で1機能1コミットを実現する 上の図のように、作業ディレクトリ（ワーキングツリー）で5個のファイルを変更していても、ステージングエリアに3個だけを乗せてコミット（ git add ➡ git commit ）し、残りの2個は次の別コミットとして記録することができます。 ...

▲ Day 08: 変更の確認と差分比較（status / diff） 👨‍🏫 専任講師からのメッセージ 受講生の皆様、お疲れ様です！ 第8回講義へようこそ。 C#で機能を実装したりバグを直している最中に、こんな経験はありませんか？ 「熱中してコードを書き換えていたら、どこを修正したか分からなくなった」 「動作確認でエラーが出たが、直前に何をいじったか思い出せない」 「SVNなら svn diff で一発だったのに、Gitで git diff を叩いても何も表示されない！？」 Gitにおける「差分の確認」は、単なるコード比較ではありません。 バグの混入を未然に防ぎ、壊れた箇所を瞬時に突き止めるための最重要セーフティネット です。本日は、コマンドラインでの厳密な差分把握から、TortoiseMergeによる視覚的2画面比較、そして最新のAIエージェント（Claude Code / Antigravity）を用いた差分要約とリスクレビューまで完全解説します！ ① まずは現状把握！ git status の見方とスマートな短縮表示 コミットを作成する前、あるいは作業を再開する際に必ず実行すべき基本コマンドが git status です。Git管理下のファイル群が「現在どの状態にあるのか」を色分けとセクションで教えてくれます。 しかし、通常の git status は解説文が多く縦に長くなりがちです。現場のプロが愛用しているのが、 短縮表示オプション git status -s （ --short ） です。 $ git status -s M src/Services/OrderService.cs # 左が緑M: ステージング済み（コミット準備OK） M src/Models/User.cs # 右が赤M: 作業...

▲ Day 07: Docker Desktop推奨設定とWSL2リソース最適化 🐳 皆さん、こんにちは！ Docker/コンテナ実践講座の専任講師です。 前回のDay 06では、Windows 11上にWSL2とDocker Desktopを導入し、本物のLinuxコンテナが動く環境を手に入れました。 しかし、初期設定のまま使い続けると、 「なぜかWindowsの動作が重い」「タスクマネージャーのVmmemがメモリを12GBも食っている」「SSDの空き容量がいつの間にか数十GB減っている」 というトラブルに必ず直面します。 本日は、ベテランエンジニアが安心して日常開発に没頭できるよう、 ホストPCを軽く保つリソース最適化とディスク管理の黄金設定 を完全伝授します！ ① 導入・本日の達成目標 従来のHyper-VやVMwareでは、「仮想マシン作成時にメモリ4GBを固定割り当て」するのが当たり前でした。 一方、WSL2は 「動的メモリ確保（ホストのメモリを最大80%まで自動拡張）」 という挙動を取るため、何も制限しないとホストWindows側のメモリを食い尽くしてしまいます。 本日の講義を終える頃には、以下の3つの目標を完全にマスターできます。 .wslconfig ファイルを用いたCPU・メモリ・スワップの制限設定 を正しく行い、ホストWindowsの快適性を100%保護する。 Docker Desktopの推奨設定（WSL Integration / Docker Engineデーモン設定） を適用し、不要なオーバーヘッドを排除する。 ビルドキャッシュや未使用イメージで肥大化する 仮想ディスク（ ext4.vhdx ）のダイエットと定期メンテナンス手順 を習得する。 ② なぜPCが重...

👨‍🏫 皆さん、こんにちは！ 本日の講座へようこそ。 前回（Day 05）では、C#プロジェクトを git init で初期化し、Gitの「3つの領域（ワークツリー ➡ ステージ ➡ 金庫）」を行き来する基本を学びました。 本日は第6回として、C#開発者が絶対にマスターしなければならない最重要防衛ライン、 「C#特化の .gitignore 完全マスター 〜bin/objの事故を防ぐ〜」 を徹底解説します！ ① 導入・本日の達成目標 「ビルドするたびに変更ファイルが何十個も出てきて、大事なソースコードの差分が埋もれてしまう…」 「他の人の環境設定（ .suo や .user ）がコミットされてしまい、Visual Studioでビルドが通らなくなった！」 これらは、VSS/SVNからGitに移行した開発チームが**100%必ず経験する代表的なトラブル**です。 Gitでは、一度コミットしてしまうと過去の全履歴の中に巨大なDLLやバイナリが永遠に残り続け、リポジトリが数GBに肥大化してクローンが激重になってしまいます。 本日のゴールは以下の3点です： なぜ bin/ , obj/ , .vs/ , *.user などのファイルを**絶対にコミットしてはいけないのか**、その理由を完全理解する。 Microsoft公式の dotnet new gitignore を活用した**プロ仕様の .gitignore 設定**を習得する。 万が一、誤ってコミットしてしまった場合の**「救済コマンド（ git rm --cached ）」**をマスターする。 ② なぜ .gitignore が必要なのか？ 〜SVNとの決定的な違い〜 C...