C#の.gitignore設定完全ガイド｜Visual Studio不要ファイルを除外してGit管理を失敗しない方法

はじめに

C#プロジェクトをGitで管理するとき、最初に設定しておきたいのが.gitignoreです。

C#開発では、ビルド時に生成されるbin/やobj/、Visual Studioが作成する.vs/、個人環境に依存する.userファイルなど、GitHubに上げる必要のないファイルが多く発生します。これらをそのままGit管理してしまうと、リポジトリが肥大化したり、チームメンバーごとの環境差分で不要な変更が大量に出たり、最悪の場合は機密情報を公開してしまったりする可能性があります。

この記事では、c# gitignoreで悩んでいる方向けに、C#開発で除外すべきファイル、管理すべきファイル、Visual Studio・.NET CLI・VS Code・Riderで使える.gitignore設定、さらに.gitignoreが効かないときの対処法まで解説します。

1. C#開発で.gitignoreが必要な理由

1-1. .gitignoreとは何か

.gitignoreとは、Gitで管理しないファイルやフォルダを指定するための設定ファイルです。

Gitは通常、リポジトリ内にあるファイルの変更を追跡します。しかし、すべてのファイルをGitで管理すべきとは限りません。たとえば、ビルド結果、キャッシュ、一時ファイル、IDEの個人設定、ログファイルなどは、ソースコードとは異なり、共有する必要がないことがほとんどです。

.gitignoreに除外ルールを書いておくことで、Gitは対象ファイルを未追跡ファイルとして扱い、git statusにも表示しなくなります。

たとえば、C#プロジェクトでよく使う設定は次のようなものです。

gitignore
bin/
obj/
.vs/
*.user
*.suo

この設定により、C#のビルド成果物やVisual Studioの個人設定ファイルをGit管理から除外できます。

1-2. C#・Visual Studio開発で不要ファイルが増えやすい理由

C#開発では、Visual Studioや.NET SDKが多くの補助ファイルを自動生成します。

代表的なものが、bin/とobj/です。bin/にはビルドされた実行ファイルやDLLが出力され、obj/にはビルド途中の中間ファイルが生成されます。これらはソースコードから再生成できるため、GitHubに上げる必要はありません。

また、Visual Studioを使っている場合は、.vs/フォルダが作成されます。このフォルダには、ソリューションの表示状態、デバッグ情報、ユーザーごとの作業状態などが保存されます。これも開発者の環境に依存するため、チームで共有すべきファイルではありません。

さらに、.user、.suo、*.rsuserなどのファイルも、個人のIDE設定やデバッグ設定を含むことがあります。そのため、C#プロジェクトでは.gitignoreを設定しないと、不要ファイルがすぐに増えてしまいます。

1-3. .gitignoreを設定しないと起こるGit管理の失敗例

.gitignoreを設定しないままC#プロジェクトをGit管理すると、さまざまなトラブルが起こります。

まず、bin/やobj/をコミットしてしまうと、ビルドのたびに大量の差分が発生します。本来レビューすべきソースコードの変更が埋もれてしまい、プルリクエストの確認がしづらくなります。

次に、.vs/や.userファイルを共有してしまうと、他の開発者のVisual Studio環境に不要な影響を与える可能性があります。自分のローカル設定がチーム全体に反映されてしまうため、環境差分による衝突が起こりやすくなります。

また、ログファイルや設定ファイルの中にAPIキー、接続文字列、パスワードなどが含まれている場合、誤ってGitHubに公開してしまうリスクもあります。特にパブリックリポジトリでは重大な問題になるため、.gitignoreによる事前対策が重要です。

1-4. GitHubに上げるべきファイル・上げないべきファイルの考え方

C#プロジェクトでGitHubに上げるべきかどうかは、「そのファイルがプロジェクトの再現に必要か」で判断するとわかりやすいです。

基本的にGit管理すべきものは、ソースコード、プロジェクトファイル、ソリューションファイル、共有設定、テストコード、ドキュメントなどです。たとえば、.cs、.csproj、.sln、README.md、Directory.Build.propsなどは通常Gitで管理します。

一方で、Git管理しない方がよいものは、ビルドすれば再生成できるファイル、個人環境に依存するファイル、機密情報を含むファイル、一時的に作られるファイルです。たとえば、bin/、obj/、.vs/、*.user、ログファイル、キャッシュファイルなどが該当します。

判断に迷った場合は、別のPCでリポジトリをクローンしたときに、そのファイルがなくてもビルド・実行できるかを基準にするとよいでしょう。

2. C#プロジェクトで除外すべき代表的なファイル・フォルダ

2-1. bin/とobj/を除外する理由

C#の.gitignoreで最も重要なのが、bin/とobj/の除外です。

bin/は、ビルド後の成果物が出力されるフォルダです。たとえば、.exe、.dll、.pdb、.deps.json、.runtimeconfig.jsonなどが生成されます。

obj/は、ビルド途中の中間ファイルが保存されるフォルダです。NuGetパッケージの復元情報や一時的なコンパイルデータなどが含まれます。

これらのファイルは、ソースコードと.csprojがあれば再生成できます。そのため、Gitに含める必要はありません。むしろ、環境やビルド構成によって内容が変わるため、Git管理すると不要な差分やコンフリクトの原因になります。

.gitignoreには次のように書きます。

gitignore
bin/
obj/

複数のプロジェクトを含むソリューションでも、この指定で各階層のbin/とobj/を除外できます。

2-2. .vs/を除外する理由

.vs/は、Visual Studioがソリューション単位で作成する隠しフォルダです。

このフォルダには、Visual Studioの作業状態、ユーザー固有の設定、デバッグ関連のキャッシュなどが保存されます。これらは開発者ごとに異なるため、Gitで共有する必要はありません。

.vs/をGit管理してしまうと、他のメンバーの環境と衝突したり、Visual Studioの状態が不安定になったりすることがあります。また、ファイルサイズが大きくなる場合もあります。

.gitignoreには次のように書きます。

gitignore
.vs/

Visual Studioを使うC#プロジェクトでは、ほぼ必須の除外設定と考えてよいでしょう。

2-3. .user・.suo・*.rsuserなど個人設定ファイル

C#開発では、IDEや拡張機能がユーザーごとの設定ファイルを作成することがあります。

代表的なものは次のとおりです。

gitignore
*.user
*.suo
*.userosscache
*.sln.docstates
*.rsuser

.userファイルには、デバッグ設定、ローカルパス、実行時のユーザー設定などが含まれる場合があります。.suoはVisual Studioのソリューションユーザーオプションです。*.rsuserはRider関連のユーザー設定ファイルです。

これらはプロジェクト全体で共有する設定ではなく、個人環境に紐づく設定です。そのため、原則としてGit管理から除外します。

ただし、チーム全体で共有したいIDE設定がある場合は、別の共有用設定ファイルとして管理するのが一般的です。個人設定とチーム設定を混同しないことが大切です。

2-4. ログ・一時ファイル・キャッシュファイル

アプリケーションの実行中に生成されるログファイルや一時ファイルも、通常はGit管理しません。

たとえば、次のような設定を追加します。

gitignore
*.log
*.tmp
*.temp
*.cache
TestResults/

ログファイルには、エラー内容、実行環境、ユーザー情報、接続先情報などが含まれることがあります。特に本番環境や検証環境のログを誤ってGitHubに上げると、セキュリティ上の問題につながる可能性があります。

また、テスト実行時に作成されるTestResults/も、再生成可能な結果ファイルであるため、基本的には除外します。

ただし、サンプル用のログや検証データを意図的に共有したい場合は、ファイル名や配置場所を明確に分けると安全です。

2-5. NuGet関連で除外すべきファイルと管理すべきファイル

NuGet関連ファイルは、除外すべきものと管理すべきものを区別する必要があります。

基本的に、NuGetパッケージ本体はGit管理しません。パッケージはdotnet restoreやVisual Studioの復元機能で再取得できるためです。

除外対象の例は次のとおりです。

gitignore
packages/
*.nupkg

ただし、.csproj内のPackageReferenceや、古い形式で使われるpackages.configはGit管理する必要があります。これらには、どのNuGetパッケージを使うかというプロジェクトの依存関係が記録されているためです。

また、packages.lock.jsonを使って依存関係のバージョンを固定している場合は、チーム開発ではGit管理するケースが多いです。ビルド環境を再現しやすくするため、プロジェクト方針に合わせて扱いを決めましょう。

3. C#向け.gitignoreの基本テンプレート

3-1. まず使えるC#用.gitignoreサンプル

C#プロジェクトで最低限使える.gitignoreは次のとおりです。

gitignore
# Build results
bin/
obj/

# Visual Studio
.vs/
*.user
*.suo
*.userosscache
*.sln.docstates

# Rider
*.rsuser
.idea/

# Logs and temporary files
*.log
*.tmp
*.temp
*.cache

# Test results
TestResults/
coverage/
*.coverage
*.coveragexml

# NuGet
packages/
*.nupkg

# OS files
.DS_Store
Thumbs.db

このテンプレートをプロジェクト直下に配置すれば、C#開発でよく発生する不要ファイルの多くを除外できます。

ただし、プロジェクトによって必要な設定は異なります。Visual Studioだけを使うのか、VS Codeを使うのか、Riderを使うのか、Unityを含むのかによって、追加すべきルールが変わります。

3-2. Visual Studio向けの除外設定

Visual Studioを使う場合は、次の設定を入れておくと安心です。

gitignore
.vs/
*.user
*.suo
*.userosscache
*.sln.docstates
[Bb]in/
[Oo]bj/

[Bb]in/や[Oo]bj/のように書くと、binとBin、objとObjのような大文字小文字の違いにも対応できます。

Visual Studioでは、ソリューションを開いたときやデバッグを実行したときに、ユーザー固有のファイルが生成されます。これらをGit管理から除外することで、不要な差分を防げます。

一方で、.slnや.csprojは基本的に除外しません。これらはプロジェクト構成を表す重要なファイルであり、チームで共有する必要があります。

3-3. .NET CLI・VS Code開発向けの除外設定

.NET CLIやVS CodeでC#開発を行う場合も、bin/とobj/は必ず除外します。

gitignore
bin/
obj/

VS Codeを使っている場合、.vscode/フォルダの扱いはプロジェクト方針によって分かれます。

個人の設定だけを保存している場合は、次のように除外しても問題ありません。

gitignore
.vscode/

一方で、チーム共通のデバッグ設定や推奨拡張機能を共有したい場合は、.vscode/settings.jsonや.vscode/launch.json、.vscode/extensions.jsonを管理することがあります。

その場合は、個人設定だけを除外するように調整します。

gitignore
.vscode/*
!.vscode/settings.json
!.vscode/launch.json
!.vscode/tasks.json
!.vscode/extensions.json

VS Codeでは、何を共有し、何を個人設定として除外するかをチームで決めておくと運用しやすくなります。

3-4. Riderを使う場合の除外設定

JetBrains Riderを使う場合は、Rider関連の設定ファイルにも注意が必要です。

代表的な除外設定は次のとおりです。

gitignore
.idea/
*.sln.iml
*.rsuser

.idea/にはJetBrains IDEの設定が保存されます。ただし、.idea/の中にはチームで共有できる設定も含まれるため、完全に除外するか一部だけ管理するかはチーム方針によります。

個人開発であれば、.idea/を丸ごと除外しても大きな問題はありません。チーム開発では、コードスタイルや検査設定などを共有したいケースもあるため、必要に応じて除外ルールを調整しましょう。

*.rsuserはRiderのユーザー固有設定なので、基本的に除外します。

3-5. テンプレートを自分のプロジェクト向けに調整するポイント

.gitignoreはテンプレートをそのまま使うだけでなく、プロジェクトに合わせて調整することが重要です。

たとえば、Webアプリケーションならログ出力先やアップロードファイルの保存先を除外する必要があるかもしれません。デスクトップアプリなら、ローカルDBや一時出力フォルダを除外するケースがあります。ライブラリ開発なら、生成した.nupkgを除外するか、リリース用に別途管理するかを決める必要があります。

調整するときは、次の観点で考えると整理しやすいです。

・ソースコードから再生成できるか
・個人環境に依存しているか
・機密情報を含む可能性があるか
・チーム全員で共有すべき設定か
・CI/CDで必要になるファイルか

除外しすぎると、別の環境でビルドできなくなることがあります。逆に除外が足りないと、不要なファイルが混ざります。.gitignoreは「最小限の必要ファイルだけをGit管理する」ための調整が大切です。

4. .gitignoreの作成・設定手順

4-1. プロジェクト直下に.gitignoreを作成する

もっとも基本的な方法は、プロジェクトまたはリポジトリの直下に.gitignoreファイルを作成することです。

一般的な構成は次のようになります。

MyCSharpProject/
├── .gitignore
├── MyCSharpProject.sln
├── MyCSharpProject/
│   ├── MyCSharpProject.csproj
│   └── Program.cs

.gitignoreは、通常リポジトリのルートディレクトリに置きます。複数のC#プロジェクトを含むソリューションでも、ルートに1つ配置すれば全体に適用できます。

作成後、次のようにGitの状態を確認します。

Bash
git status

bin/やobj/などが表示されなくなっていれば、.gitignoreが正しく機能しています。

4-2. GitHub公式テンプレートを利用する方法

C#用の.gitignoreを作るときは、GitHubが提供しているVisual Studio向けテンプレートを利用する方法もあります。

GitHubで新しいリポジトリを作成するとき、.gitignoreテンプレートから「VisualStudio」を選択できます。これにより、Visual StudioやC#開発でよく使われる除外設定が自動で追加されます。

すでにリポジトリを作成済みの場合でも、GitHubの.gitignoreテンプレートを参考にして、自分のプロジェクトへコピーできます。

特にVisual Studioを使うC#プロジェクトでは、公式テンプレートをベースにするのが安全です。そのうえで、プロジェクト固有のログ、キャッシュ、生成物などを追加するとよいでしょう。

4-3. dotnet new gitignoreで作成する方法

.NET CLIを使っている場合は、次のコマンドで.gitignoreを作成できます。

Bash
dotnet new gitignore

このコマンドをリポジトリのルートディレクトリで実行すると、.NET向けの一般的な.gitignoreが生成されます。

手順は次のとおりです。

Bash
cd MyCSharpProject
dotnet new gitignore

その後、必要に応じてVisual Studio、VS Code、Rider、Unityなどの設定を追加します。

.NET CLI中心で開発している場合は、この方法が簡単です。テンプレートを手作業で探す必要がなく、.NET開発向けの基本設定をすぐに用意できます。

4-4. Visual Studioから.gitignoreを追加する方法

Visual StudioからGitリポジトリを作成する場合、.gitignoreを追加できることがあります。

Visual StudioのGit関連機能を使ってリポジトリを初期化すると、Visual Studio向けの.gitignoreが自動生成される場合があります。生成されない場合は、ソリューションのルートフォルダに手動で.gitignoreを追加して問題ありません。

重要なのは、.gitignoreをソリューションファイルと同じ階層、またはリポジトリのルートに置くことです。場所がずれていると、想定したファイルが除外されないことがあります。

Visual Studioを使っていても、最終的には.gitignoreの中身を確認し、bin/、obj/、.vs/、*.userなどが含まれているかチェックしましょう。

4-5. 既存リポジトリに後から.gitignoreを追加する方法

すでにGit管理を始めた後でも、.gitignoreは追加できます。

ただし、注意点があります。.gitignoreは、まだGitで追跡されていないファイルに対して有効です。すでにコミット済みのbin/やobj/は、.gitignoreに追加しただけでは管理対象から外れません。

後から追加する手順は次のとおりです。

Bash
# .gitignoreを作成・編集
touch .gitignore

# 追跡済みの不要ファイルをインデックスから削除
git rm -r --cached bin obj .vs

# 状態確認
git status

# コミット
git add .gitignore
git commit -m "Add gitignore for C# project"

複数の階層にbin/やobj/がある場合は、次のように一度キャッシュを全体的に外してから、必要なファイルだけ再追加する方法もあります。

Bash
git rm -r --cached .
git add .
git commit -m "Apply gitignore"

この方法は影響範囲が大きいため、実行前にgit statusで変更内容をよく確認してください。

5. .gitignoreが効かないときの原因と対処法

5-1. すでにGit管理されているファイルは除外されない

.gitignoreが効かない原因として最も多いのが、対象ファイルがすでにGitで管理されているケースです。

.gitignoreは、未追跡のファイルを無視するための設定です。すでにgit addやgit commitされたファイルは、あとから.gitignoreに書いても自動では除外されません。

たとえば、bin/をすでにコミットしてしまった後に、次の設定を追加しても、追跡は続きます。

gitignore
bin/
obj/

この場合は、Gitの管理対象から外す作業が必要です。

5-2. git rm --cachedで追跡対象から外す方法

すでにGit管理されているファイルを、ローカルには残したままGitの追跡対象から外すには、git rm --cachedを使います。

たとえば、bin/とobj/を外す場合は次のように実行します。

Bash
git rm -r --cached bin obj
git commit -m "Remove build artifacts from repository"

.vs/をGit管理してしまった場合は、次のようにします。

Bash
git rm -r --cached .vs
git commit -m "Remove Visual Studio cache from repository"

すべての追跡ファイルを一度インデックスから外し、.gitignoreを反映し直す場合は次の方法もあります。

Bash
git rm -r --cached .
git add .
git commit -m "Refresh tracked files based on gitignore"

この操作を行うと、多くのファイルが変更扱いになることがあります。コミット前に必ずgit statusで内容を確認しましょう。

5-3. パス指定・ワイルドカードの書き方ミス

.gitignoreが効かない場合、パス指定やワイルドカードの書き方が間違っている可能性もあります。

よく使う書き方は次のとおりです。

gitignore
# すべての階層のbinフォルダを除外
bin/

# ルート直下のbinだけ除外
/bin/

# 拡張子が.logのファイルを除外
*.log

# 特定のファイルを除外
appsettings.Development.json

# 除外した中で一部だけ管理する
!.gitkeep

bin/と書くと、リポジトリ内の各階層にあるbinディレクトリが除外されます。一方、/bin/と書くと、リポジトリルート直下のbinだけが対象になります。

また、除外したフォルダの中にあるファイルを例外的に管理したい場合、単純に!fileを書くだけではうまくいかないことがあります。親フォルダ自体が除外されていると、Gitが中身を見に行かないためです。その場合は、親フォルダの除外ルールも調整する必要があります。

5-4. .gitignoreの配置場所が間違っている

.gitignoreの配置場所が間違っていると、期待通りに除外されないことがあります。

通常は、リポジトリのルートディレクトリに.gitignoreを置きます。

repository-root/
├── .gitignore
├── MyApp.sln
└── src/
    └── MyApp/
        └── MyApp.csproj

リポジトリの外側に.gitignoreを置いても、そのリポジトリには適用されません。また、サブディレクトリに.gitignoreを置いた場合は、そのディレクトリ配下に対して適用されます。

C#のソリューション構成では、.slnファイルと各.csprojの位置が異なることがあります。そのため、.gitignoreはGitリポジトリのルートに置くのが基本です。

5-5. 除外できているか確認するコマンド

.gitignoreが正しく効いているか確認するには、次のコマンドを使います。

Bash
git status

除外したいファイルがUntracked filesに表示されていなければ、基本的には無視されています。

特定のファイルがどの.gitignoreルールで除外されているか確認したい場合は、次のコマンドが便利です。

Bash
git check-ignore -v path/to/file

たとえば、obj/Debugが除外されているか確認する場合は次のようにします。

Bash
git check-ignore -v MyApp/obj/Debug

除外されていれば、どの.gitignoreの何行目が適用されているか表示されます。何も表示されない場合は、ルールが一致していないか、すでにGit管理されている可能性があります。

6. C#開発で.gitignoreに書かない方がよいもの

6-1. .slnや.csprojは基本的にGit管理する

C#プロジェクトでは、.slnや.csprojを.gitignoreに入れないのが基本です。

.slnはVisual Studioのソリューション構成を表すファイルです。複数のプロジェクトをまとめる情報が含まれているため、チームで共有する必要があります。

.csprojはC#プロジェクトの設定ファイルです。ターゲットフレームワーク、参照しているNuGetパッケージ、ビルド設定、プロジェクト参照などが含まれます。これをGit管理しないと、他の開発者がプロジェクトを正しくビルドできません。

除外してはいけない代表例は次のとおりです。

*.sln
*.csproj
*.props
*.targets

ただし、自動生成される特殊なプロジェクトファイルを扱う場合は例外もあります。通常のC#アプリケーションやライブラリでは、.slnと.csprojはGit管理するものと考えて問題ありません。

6-2. packages.config・PackageReferenceの扱い

NuGetの依存関係を表すファイルも、基本的にはGit管理します。

古い形式のプロジェクトでは、packages.configにNuGetパッケージの一覧が記録されています。このファイルを除外してしまうと、他の環境で必要なパッケージを復元できなくなります。

新しいSDKスタイルのC#プロジェクトでは、.csproj内のPackageReferenceで依存関係を管理することが一般的です。この場合も、.csprojをGit管理することで依存関係を共有できます。

つまり、NuGetパッケージ本体は除外してよいですが、依存関係を記録するファイルは管理する必要があります。

除外しないものの例は次のとおりです。

packages.config
*.csproj
packages.lock.json

packages.lock.jsonはプロジェクト方針によりますが、再現性を高めたい場合はGit管理することが多いです。

6-3. appsettings.jsonと機密情報の注意点

ASP.NET Coreなどでは、appsettings.jsonやappsettings.Development.jsonの扱いに注意が必要です。

appsettings.jsonはアプリケーションの基本設定を記述するファイルです。環境に依存しない設定であれば、Git管理することが一般的です。

一方で、接続文字列、APIキー、パスワード、トークンなどの機密情報はGitに含めるべきではありません。特にパブリックリポジトリでは非常に危険です。

よくある運用は、共有してよいテンプレートだけをGit管理し、実際の機密情報は環境変数やユーザーシークレット、CI/CDのシークレット機能で管理する方法です。

例として、次のようにします。

gitignore
appsettings.Development.json
appsettings.Local.json

そして、共有用にサンプルファイルを用意します。

appsettings.example.json

ただし、appsettings.Development.jsonをチームで共有する方針のプロジェクトもあります。その場合は、機密情報を含めないルールを徹底することが重要です。

6-4. チーム開発で共有すべき設定ファイル

.gitignoreでは、個人設定を除外する一方で、チーム全体で共有すべき設定ファイルは残す必要があります。

たとえば、次のようなファイルはGit管理することが多いです。

.editorconfig
Directory.Build.props
Directory.Build.targets
global.json
NuGet.config
README.md

.editorconfigは、インデントや改行コードなどのコードスタイルを共有するために使います。Directory.Build.propsやDirectory.Build.targetsは、複数プロジェクトに共通するビルド設定をまとめるために使います。global.jsonは使用する.NET SDKバージョンを固定したい場合に役立ちます。

NuGet.configも、社内パッケージフィードなどを使っている場合は共有が必要です。ただし、認証情報やアクセストークンを含めないよう注意してください。

6-5. 除外しすぎによるビルド不能トラブル

.gitignoreは不要ファイルを除外するためのものですが、除外しすぎると別の環境でビルドできなくなることがあります。

たとえば、.csprojやpackages.configを除外すると、プロジェクト構成や依存関係がわからなくなります。設定ファイルをまとめて除外してしまうと、アプリケーション起動に必要なファイルが不足することもあります。

特に次のような雑な指定には注意が必要です。

gitignore
*.config
*.json
*.csproj

このような設定を入れると、本来必要なファイルまで除外される可能性があります。

C#プロジェクトでは、生成物や個人設定を除外し、プロジェクト再現に必要なファイルは残すのが基本です。.gitignoreを変更したら、別の環境でクローンしてビルドできるか確認すると安全です。

7. 実務で使いやすいC#用.gitignore完成例

7-1. Visual Studio向け完成版

Visual StudioでC#開発を行う場合の.gitignore完成例は次のとおりです。

gitignore
# Build results
[Bb]in/
[Oo]bj/
[Dd]ebug/
[Rr]elease/
x64/
x86/
[Aa][Rr][Mm]/
[Aa][Rr][Mm]64/

# Visual Studio
.vs/
*.user
*.rsuser
*.suo
*.userosscache
*.sln.docstates

# Visual Studio cache/options
*.VC.db
*.VC.VC.opendb
*.opendb

# Test results
[Tt]est[Rr]esult*/
*.trx
*.coverage
*.coveragexml
coverage/

# NuGet
packages/
*.nupkg
.nuget/

# Logs and temporary files
*.log
*.tmp
*.temp
*.cache

# OS files
.DS_Store
Thumbs.db
ehthumbs.db
Desktop.ini

この設定は、Visual Studioで作成される代表的な不要ファイルを広く除外できます。通常のC#アプリケーション、クラスライブラリ、ASP.NET Coreアプリなどで使いやすい内容です。

ただし、Debug/やRelease/を出力フォルダ以外の用途で使っている場合は注意してください。プロジェクト固有のディレクトリ構成に合わせて調整しましょう。

7-2. .NET Core・.NET 5以降向け完成版

.NET Core、.NET 5以降、.NET 6、.NET 7、.NET 8などのSDKスタイルプロジェクトでは、次のような.gitignoreが使いやすいです。

gitignore
# .NET build output
bin/
obj/

# User-specific files
*.user
*.rsuser
*.suo

# Visual Studio
.vs/

# VS Code
.vscode/*
!.vscode/settings.json
!.vscode/launch.json
!.vscode/tasks.json
!.vscode/extensions.json

# Test results and coverage
TestResults/
coverage/
*.coverage
*.coveragexml
*.trx

# NuGet
packages/
*.nupkg

# Publish output
publish/
artifacts/

# Logs and temp
*.log
*.tmp
*.temp
*.cache

# OS files
.DS_Store
Thumbs.db

.NET CLIやVS Code中心の開発では、Visual Studio固有の設定を最小限にしつつ、bin/、obj/、テスト結果、カバレッジ、publish成果物を除外する構成が扱いやすいです。

artifacts/をビルド出力先として使っている場合は除外対象に含めます。一方で、リリース用の成果物を意図的に管理する運用であれば、除外しない選択もあります。

7-3. Unityを含むC#プロジェクトの場合

UnityもC#を使いますが、通常の.NETプロジェクトとは.gitignoreの考え方が少し異なります。

Unityでは、Library/、Temp/、Obj/、Build/、Logs/などを除外するのが一般的です。一方で、Assets/やProjectSettings/はプロジェクト再現に必要なため、Git管理します。

Unity向けの例は次のとおりです。

gitignore
# Unity generated folders
[Ll]ibrary/
[Tt]emp/
[Oo]bj/
[Bb]uild/
[Bb]uilds/
[Ll]ogs/
[Uu]ser[Ss]ettings/

# Unity generated files
*.csproj
*.sln
*.user
*.userprefs
*.pidb
*.booproj
*.svd

# Visual Studio
.vs/

# OS files
.DS_Store
Thumbs.db

Unityでは、.csprojや.slnがUnityによって自動生成される場合が多いため、通常のC#プロジェクトとは違って除外することがあります。

ただし、Unity以外の通常のC#プロジェクトでは、.csprojや.slnは基本的にGit管理します。この違いを混同しないようにしましょう。

7-4. 個人開発とチーム開発での使い分け

個人開発では、多少広めに除外しても問題になりにくいです。自分の環境で不要なファイルを除外し、リポジトリを軽く保つことを優先できます。

一方で、チーム開発では「他のメンバーがクローンしてすぐに開発できるか」が重要です。個人設定は除外しつつ、ビルドや実行に必要な設定はGit管理する必要があります。

チーム開発で特に確認したいファイルは次のとおりです。

.sln
.csproj
.editorconfig
Directory.Build.props
global.json
NuGet.config
appsettings.example.json

また、.vscode/や.idea/をどこまで共有するかもチームで決めておくとよいでしょう。個人の好みが強い設定は除外し、フォーマットやビルドに関わる設定は共有するのが一般的です。

7-5. コピペ後に確認すべきチェックリスト

.gitignoreをコピペした後は、次の項目を確認しましょう。

・bin/とobj/が除外されているか
・.vs/が除外されているか
・*.user、*.suo、*.rsuserが除外されているか
・.slnと.csprojを誤って除外していないか
・NuGetの依存関係ファイルを除外していないか
・機密情報を含む設定ファイルがGit管理されていないか
・チームで共有すべき設定ファイルまで除外していないか
・git statusで不要ファイルが表示されないか
・すでに追跡済みの不要ファイルをgit rm --cachedで外したか

特に、.gitignoreを後から追加した場合は、すでにGit管理されている不要ファイルが残っていないか確認することが重要です。

8. C#の.gitignore設定に関するよくある質問

8-1. binとobjは削除しても問題ない？

通常のC#プロジェクトでは、bin/とobj/は削除しても問題ありません。

これらはビルド時に再生成されるフォルダです。Visual Studioでビルドするか、次のコマンドを実行すれば再作成されます。

Bash
dotnet build

ビルドエラーや参照エラーが発生したときに、bin/やobj/を削除してから再ビルドすると解決することもあります。

Bash
dotnet clean
dotnet build

ただし、手動で置いたファイルをbin/やobj/に保存している場合は注意が必要です。基本的に、これらのフォルダには重要な手作業ファイルを置かないようにしましょう。

8-2. .vsフォルダをGitHubに上げてしまった場合は？

.vs/をGitHubに上げてしまった場合は、.gitignoreに.vs/を追加し、Gitの追跡対象から外します。

手順は次のとおりです。

gitignore
.vs/

その後、次のコマンドを実行します。

Bash
git rm -r --cached .vs
git commit -m "Remove .vs folder from repository"

これでローカルの.vs/フォルダは残したまま、Git管理から外せます。

ただし、過去のコミット履歴には.vs/が残ります。もし機密情報を含むファイルを公開してしまった場合は、履歴からの削除やシークレットの無効化・再発行など、追加対応が必要です。

8-3. .csprojは.gitignoreに入れるべき？

通常のC#プロジェクトでは、.csprojを.gitignoreに入れるべきではありません。

.csprojには、ターゲットフレームワーク、NuGetパッケージ、プロジェクト参照、ビルド設定など、プロジェクトを再現するために必要な情報が含まれています。

.csprojをGit管理しないと、他の開発者やCI環境でビルドできなくなる可能性があります。

例外として、Unityプロジェクトでは.csprojが自動生成されるため、除外することがあります。しかし、通常のコンソールアプリ、Webアプリ、クラスライブラリ、ASP.NET Coreプロジェクトでは、.csprojはGit管理するのが基本です。

8-4. appsettings.Development.jsonは除外すべき？

appsettings.Development.jsonを除外すべきかどうかは、プロジェクト方針によります。

ローカル環境の接続文字列、APIキー、パスワードなどを含む場合は、Git管理しない方が安全です。

gitignore
appsettings.Development.json
appsettings.Local.json

一方で、チーム全員が共有してよい開発用設定だけを入れている場合は、Git管理することもあります。

おすすめは、機密情報を含めないサンプルファイルを用意する方法です。

appsettings.example.json

実際の値は、環境変数、ユーザーシークレット、CI/CDのシークレット設定などで管理すると安全です。

8-5. GitHub DesktopやVisual Studioでも同じ設定で使える？

はい、.gitignoreの基本的な仕組みはGitの機能なので、GitHub Desktop、Visual Studio、VS Code、Rider、コマンドラインのどれを使っていても同じように機能します。

重要なのは、.gitignoreがリポジトリ内の正しい場所にあり、除外ルールが適切に書かれていることです。

ただし、すでにGit管理されているファイルは、ツールに関係なく.gitignoreだけでは除外されません。その場合は、git rm --cachedで追跡対象から外す必要があります。

Bash
git rm -r --cached bin obj .vs
git commit -m "Remove ignored files"

Visual StudioやGitHub Desktopを使っている場合でも、必要に応じてターミナルからGitコマンドを実行すると確実です。

まとめ

C#プロジェクトをGitで安全に管理するには、.gitignoreの設定が欠かせません。

特に、bin/、obj/、.vs/、*.user、*.suo、*.rsuser、ログファイル、一時ファイル、テスト結果などは、GitHubに上げる必要がない代表的なファイルです。これらを除外することで、リポジトリを軽く保ち、不要な差分やコンフリクトを防げます。

一方で、.sln、.csproj、packages.config、PackageReferenceを含むプロジェクトファイル、.editorconfig、Directory.Build.propsなどは、プロジェクトの再現に必要なため、基本的にGit管理します。

.gitignoreが効かない場合は、すでにGitで追跡されている可能性があります。その場合は、git rm --cachedを使って追跡対象から外しましょう。

C#の.gitignore設定では、「再生成できるもの」「個人環境に依存するもの」「機密情報を含むもの」は除外し、「プロジェクトを再現するために必要なもの」は管理する、という考え方が基本です。

最初に適切な.gitignoreを用意しておけば、Visual Studio、VS Code、Rider、GitHub Desktopのどれを使っていても、Git管理のトラブルを大きく減らせます。