Should I commit the .vscode folder to source control?

Solution 1:

Check in the .vscode folder if you want to share settings, task configuration and debug configuration with the team. I think generally it makes sense to share settings (e.g. whitespace vs tabs) with the team if you want to enforce settings in a team. We in the VS Code team share debug and task specific settings as well because we want our team to have the same set of debug targets and task targets for VS Code.

Btw you do not need to have a .vscode folder in your project for settings. You can also configure settings on a user level.

Solution 2:

Summing up other answers

Recommendation is to generally exclude .vscode folder, but leave select JSON files that allow other developers to recreate shared settings.

Examples of settings to include:

• Language specific test configurations to run the test suite(s) (settings.json)
• Extension settings for linters and code formatting tools to enforce the language rules used in this repo (settings.json)
• Run and debug configurations (launch.json)
• Shared tasks - if managed with VS Code (tasks.json)

Note that some settings can be stored in the user settings or workspace file, or transferred to it from the .vscode folder. See below.

Sample .gitignore code

Here are the settings, as suggested at https://gitignore.io. You can search for "VisualStudioCode" there to get the latest recommended .gitignore file. I use this website as a starting point for .gitignore for most of my new repos:

# Created by https://www.gitignore.io/api/visualstudiocode
# Edit at https://www.gitignore.io/?templates=visualstudiocode

### VisualStudioCode ###
.vscode/*      # Maybe .vscode/**/* instead - see comments
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json

### VisualStudioCode Patch ###
# Ignore all local history of files
**/.history

# End of https://www.gitignore.io/api/visualstudiocode

In the above .gitignore file, the .vscode/* line (note: some debate on whether the * should be included - see comments; .vscode/**/* may be better to ignore nested folders as well) says to exclude everything in the .vscode folder, but then the !.vscode/a_specific_file lines tell git to "not" ignore some specific files in that folder (settings.json, launch.json, etc.). The end result is that everything is excluded in the .vscode folder except for the files specifically named in one of those other lines.

Other Factors

Including the .vscode folder in your repo doesn't actually hurt anyone that uses a different IDE (or text/code editor).

However, it may cause issues for other people using VS Code, or some of the settings may not load properly, if these files include generic settings that require something specific to your environment - like the absolute path the repo is installed in. The key is to avoid saving settings that are custom to your local environment, only sharing those that can be used by everyone.

For example, if IDE setting files have absolute paths to the repo or any files/libraries, etc., then that is bad, don't share. But if all the references are relative, then they should work for anyone using the repo (although, be careful about path specification differences between Windows/Unix..).

About User, Workspace, and Folder settings

Note: the settings files in the .vscode folder are generally updated when you make changes to the folder version of the settings - but this appears to depend on how individual extensions are coded, because I've run across multiple exceptions to this rule.

• If you make changes to the user settings, they are usually stored elsewhere (location depends on OS settings, usually in a home directory).
• If you make changes to the workspace settings, they are usually stored in the *.code-workspace file that you are currently using. If you don't have a workspace (you directly opened a folder instead), then they will likely go to the .vscode folder, but, overall, this may depend on the extension that owns the setting anyway.

So, you should generally put custom settings for your personal PC into the user settings, and put generic settings into the workspace or folder settings.

• Exception example: the Python extension updates .vscode/settings.json to have an absolute path of the current folder under the pythonpath setting, which makes it specific to the current PC.

Solution 3:

Between commit/ignore there is third clever option: commit with .default suffix.

For example you can add settings.json to .gitignore, and commit settings.json.default, much like it is common practice (in my team) with .env files.

I took this advice from video Commit editor settings to version control? by Mattias Petter Johansson