Visual Studio＋GitHub Desktopで新しいファイルを追加したときの注意点

広告

Visual StudioでWindowsフォームアプリを作成し、GitHub DesktopでGit管理しているとき、

「変更したファイルを保存して、そのファイルをコミットすればよい」

と考えがちです。

既存のC#ファイルを少し修正しただけなら、基本的にはそれでも問題ありません。

しかし、新しいクラスやフォームなどを追加した場合は注意が必要です。

大切なのは、

自分が編集したファイルだけを見るのではなく、その作業によってVisual Studioが変更・追加したファイル全体を確認してコミットする

という考え方です。

既存ファイルを変更した場合

例えば、すでに存在している Player.cs を変更したとします。

public class Player
{
    public string Name { get; set; }

    public void ShowName()
    {
        Console.WriteLine(Name);
    }
}

このファイルを変更した場合は、

  1. Visual Studioで保存する
  2. GitHub Desktopを開く
  3. Changes を確認する
  4. Player.cs の変更内容を確認する
  5. コミットする
  6. Pushする

という流れになります。

比較的分かりやすいケースです。

新しいファイルを追加した場合はどうなる？

今度はVisual Studioで、

Player.cs

という新しいクラスを追加したとします。

この場合、

「Player.csを保存したから、Player.csだけコミットすればよい」

と考えるのは少し危険です。

Visual Studioでは、操作内容によっては新しいファイル以外のファイルも変更されることがあります。

例えば、

Player.cs
SampleApp.csproj

のように、プロジェクトファイルも変更される場合があります。

そのため、

新しく追加したファイルだけを見るのではなく、GitHub DesktopのChangesに何が表示されているか確認する

ことが重要です。

「すべて保存」をしてからGitHub Desktopを確認する

Visual Studioでは、編集したファイルだけでなく、プロジェクトに関係する情報が変更される場合があります。

そのため、Gitへコミットする前には、

［ファイル］→［すべて保存］

または、

Ctrl + Shift + S

などを使って、Visual Studio側の変更を保存しておくと安全です。

そのうえでGitHub Desktopを開きます。

ここで重要なのは、

「どのファイルを保存したか」ではなく、「この作業によって何が変更されたか」

を見ることです。

GitHub DesktopのChangesを必ず確認する

例えば、新しいクラスを追加したあとにGitHub Desktopを見ると、

Changes

✓ Player.cs
✓ SampleApp.csproj

のように複数の変更が表示されることがあります。

この場合、

Player.cs

だけをコミットするのではなく、

Player.cs
SampleApp.csproj

の両方が今回の作業に必要な変更なのか確認します。

必要な変更であれば、一緒にコミットします。

.NET Frameworkでは特に重要

従来の.NET Framework形式のプロジェクトでは、C#ファイルがプロジェクトファイル .csproj に明示的に登録されています。

例えば、

<ItemGroup>
  <Compile Include="Player.cs" />
</ItemGroup>

のような情報です。

そのため、

Player.cs

だけをGitへ登録して、

SampleApp.csproj

の変更をコミットし忘れると、

他のメンバーがPullしたときに、

Player.csはフォルダに存在する

        ↓

しかしプロジェクトに正しく登録されていない

        ↓

Visual Studioのソリューションエクスプローラーで
期待した状態にならない

という問題が起こる可能性があります。

.NET Frameworkなどの非SDK形式では、ソースファイルをプロジェクトファイル内に明示的に列挙する仕組みになっています。 (⁠Microsoft Learn)

現在の.NETでは少し仕組みが違う

ここは重要です。

.NET 8、.NET 9、.NET 10など、現在のSDK形式の.NETプロジェクトでは、通常、

<Compile Include="Player.cs" />

のように1ファイルずつ .csproj に登録する必要はありません。

.NET SDKでは基本的に、

**/*.cs

というルールによって、プロジェクトフォルダ以下のC#ファイルを自動的にコンパイル対象にします。 (⁠Microsoft Learn)

例えば、

SampleApp
├─ Form1.cs
├─ Program.cs
└─ Player.cs

となっていれば、通常は Player.cs も自動的にプロジェクトへ含まれます。

そのため現在の.NETでは、

新しいC#ファイルを追加したら必ず .csproj が変更される

とは限りません。

ここは.NET Frameworkとの大きな違いです。

それでもChangesを全部確認する習慣が大切

「現在の.NETなら .csproj を気にしなくてよい」

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

例えば、

  • NuGetパッケージを追加した
  • プロジェクト参照を追加した
  • ビルド設定を変更した
  • ファイルのビルドアクションを変更した
  • リソースを追加した

といった操作では、.csproj が変更されることがあります。

つまり、環境によって、

Player.csだけ

の場合もあれば、

Player.cs
SampleApp.csproj

になる場合もあります。

だからこそ、

どのファイルをコミットするかを最初から決めつけない

ことが重要です。

Windowsフォームを追加するとさらに注意

Windowsフォームでは、さらに分かりやすい例があります。

Visual Studioで、

Form2

という新しいフォームを追加すると、実際には複数のファイルで構成されます。

例えば、

Form2.cs
Form2.Designer.cs
Form2.resx

です。

MicrosoftのWindows Formsドキュメントでも、フォームは基本的に .cs と .Designer.cs、必要に応じて .resx によって構成されることが説明されています。 (⁠Microsoft Learn)

そのため、

「私はForm2.csしか書いていないから、Form2.csだけコミットする」

としてしまうと、必要なファイルをGitに登録し忘れる可能性があります。

Designer.csは自分で書いていなくても必要

例えばフォームデザイナーでボタンを1個配置すると、Visual Studioが自動的に、

private System.Windows.Forms.Button button1;

などのコードを Form2.Designer.cs に生成します。

自分で直接編集していなくても、

Form2.Designer.cs

はそのフォームを構成する重要なファイルです。

同じように、

Form2.resx

にもフォームで使用するリソースなどの情報が保存されることがあります。

つまり、

「自分が書いたファイル」＝「Gitに必要なファイル」ではありません。

よくある失敗

例えばAさんが新しいフォームを追加したとします。

GitHub Desktopには、

Form2.cs
Form2.Designer.cs
Form2.resx

が表示されました。

ところがAさんが、

Form2.cs

だけにチェックを付けてコミット・Pushしたとします。

BさんがPullすると、

Form2.cs

しか受け取れません。

Aさんのパソコンでは正常に動いていたのに、

Bさんの環境ではフォームが正しく表示されない
ビルドエラーになる
デザイナーが開けない

といった問題につながる可能性があります。

Gitが壊れているわけではありません。

Gitは、

コミットされたものを正確に受け取っているだけ

です。

必要なファイルが最初からコミットされていなければ、Pullしても受け取ることはできません。

Gitは「Visual Studioのプロジェクト」を理解しているわけではない

ここも大切なポイントです。

Gitは、

これはWindowsフォームだから、
Designer.csも必要だろう

などとは判断してくれません。

Gitが管理しているのは基本的に、

どのファイルが追加されたか
どのファイルが変更されたか
どのファイルが削除されたか

という情報です。

そのため、

Form2.csだけコミット

すれば、GitHubに送られるのも基本的にはその変更だけです。

GitHub Desktopも、

「このファイルも必要ですよ」

とVisual Studioの設計意図まで理解して自動判断してくれるわけではありません。

コミット前のおすすめ手順

Visual Studio＋GitHub Desktopでは、次の流れを習慣にすると安全です。

① Visual Studioで作業する

クラス追加、フォーム追加、コード修正などを行います。

② Visual Studioですべて保存する

すべて保存

を実行します。

③ GitHub Desktopを開く

Changes を確認します。

④ Changesに表示されたファイルを見る

例えば、

Player.cs
Form1.cs
Form1.Designer.cs
SampleApp.csproj

などが表示されていたら、

「なぜこのファイルが変更されたのか」

を考えます。

⑤ 今回の作業に必要な変更をまとめてコミットする

例えば、

プレイヤークラスを追加

という作業で発生した変更なら、その作業に必要なファイルをまとめます。

⑥ Pushする

コミットしただけではGitHubには送られていません。

最後に、

Push origin

します。

「全部コミットすればよい」ではない

ここで注意したいのが、

Changesに出ているものは何でも全部コミットすればよい

という意味ではないことです。

例えば、

Player.cs
Form1.cs

を変更したあと、

まったく関係のない、

Test.cs

も途中で編集していた場合、

すべてを1つのコミットにまとめると、変更内容が分かりにくくなります。

理想は、

1つの目的に必要な変更を1つのコミットにまとめる

ことです。

例えば、

プレイヤークラスを追加

というコミットなら、その機能追加に必要な変更をまとめます。

チーム開発では特に重要

1人で開発していると、

「自分のパソコンでは動いているから大丈夫」

となりがちです。

しかしチーム開発では、

Aさん
Visual Studioで作業
↓
Commit
↓
Push
↓
GitHub
↓
Pull
↓
Bさん
Visual Studioで開く

という流れになります。

Bさんのパソコンには、

AさんがコミットしてPushしたものしか届きません。

Aさんのパソコンにだけ存在するファイルは届きません。

そのため、コミット前のChanges確認は非常に重要です。

初学者におすすめの確認方法

GitHub DesktopでCommitする前に、次の3つを確認してみましょう。

① 追加したはずのファイルがChangesにあるか

② Visual Studioが自動生成した関連ファイルもあるか

③ 今回の作業に関係する変更がそろっているか

特に新しいフォームを作った場合は、

.cs
.Designer.cs
.resx

などを確認します。

.NET Framework形式なら、

.csproj

の変更も確認しましょう。

覚えておきたい考え方

Gitを使い始めたばかりのときは、

「編集したファイルをコミットする」

と考えがちです。

しかし実際の開発では、

「今回の作業で発生した変更をコミットする」

と考える方が適切です。

例えば「商品登録フォームを追加する」という作業なら、

ProductForm.cs
ProductForm.Designer.cs
ProductForm.resx
必要なら .csproj
関連して変更したコード

まで含めて、

商品登録フォームを追加するために必要な変更一式

が1つのコミットになります。

まとめ

Visual Studio＋GitHub DesktopでGit管理するとき、

既存ファイルを少し編集しただけなら、そのファイルの変更だけで済むこともあります。

しかし、

  • 新しいクラスを追加した
  • 新しいフォームを追加した
  • ファイルを削除した
  • ファイル名を変更した
  • NuGetパッケージを追加した
  • プロジェクト設定を変更した

といった場合は、複数のファイルが変更される可能性があります。

そのため、

Visual Studioですべて保存 → GitHub DesktopのChangesを確認 → 今回の作業に必要な変更一式をCommit → Push

という流れを習慣にしましょう。

特に覚えておきたいのは、

「自分が書いたファイル」ではなく、「今回の作業で必要になった変更」をコミットする。

という考え方です。

これができるようになると、

「自分のパソコンでは動くのに、他の人がPullすると動かない」

というチーム開発でありがちなトラブルを大幅に減らすことができます。

今回の記事は、GitHub Desktopを使ったチーム開発シリーズの「コミット前の確認」記事としてかなり相性がいい内容です。既存の記事の途中に挟むなら、「新しいファイルを追加した直後〜コミットする前」の位置に入れるのが自然です。

訪問数 2 回, 今日の訪問数 3回

広告

C#

Posted by hidepon