I personally strongly advise against committing IDE junk to version control. Assuming your IDE workspace defaults are “sane” for the rest of the contributors is not a good practice.
.vscode doesn’t store cache or any trash like that, so if you’re including all settings, tasks, etc, you can probably just include everything.
The only thing to keep in mind is to only add settings, extension recommendations, etc that apply to all your collaborators and aren’t just personal preferences. A few good examples are formatting rules, task definitions to run the project, and linting rules that can’t be defined somewhere else.
Linting rules and scripts should never live in an IDE-specific directory. I should not need to know your IDE configuration to run scripts and lint my files.
I have yet to come across a language that requires configuration to be stored that way. All modern languages have separate configuration and metadata files for use cases you have defined.
As for workspace defaults, whatever IDE configuration works for you is not guaranteed to work for others. Shoving extension suggestions down their throat each time IDE is booted should not be a part of your source code, as IDE extensions should not be needed to run your code.
Later when I git status or just look at the repo online… “oh crap I let .DS_Store in didn’t I…” and then I remember to set up a .gitignore and make a new commit to take out the .DS_Store and put in the .gitignore.
You probably already know this, but for those who don’t, git can globally ignore patterns. It’s the first thing I set up after logging in. Honestly wish git just shipped this way out of the box (maybe match .DS_Store by name and some magic bytes?) with a way to disable it. Just for the sake of easier onboarding
Just gitignore that. Same for dot idea and whatever vscode adds, if anything
Use this so that the things you need to share do get shared.
.idea/* !.idea/codeStyles !.idea/runConfigurations .vscode/* !.vscode/settings.json !.vscode/tasks.json !.vscode/launch.json !.vscode/extensions.json !.vscode/*.code-snippetsNote: I haven’t checked the vs code ones in depth, the list might not be perfect.
I personally strongly advise against committing IDE junk to version control. Assuming your IDE workspace defaults are “sane” for the rest of the contributors is not a good practice.
.vscodedoesn’t store cache or any trash like that, so if you’re including all settings, tasks, etc, you can probably just include everything.The only thing to keep in mind is to only add settings, extension recommendations, etc that apply to all your collaborators and aren’t just personal preferences. A few good examples are formatting rules, task definitions to run the project, and linting rules that can’t be defined somewhere else.
Linting rules and scripts should never live in an IDE-specific directory. I should not need to know your IDE configuration to run scripts and lint my files.
I have yet to come across a language that requires configuration to be stored that way. All modern languages have separate configuration and metadata files for use cases you have defined.
As for workspace defaults, whatever IDE configuration works for you is not guaranteed to work for others. Shoving extension suggestions down their throat each time IDE is booted should not be a part of your source code, as IDE extensions should not be needed to run your code.
Ya, but that .idea is not inserted in eleven thousand sub folders.
It’s not, but I still prefer not pushing my config on others, or others pushing theirs on me.
git add .>git commit -m "initial">git pushLater when I
git statusor just look at the repo online… “oh crap I let .DS_Store in didn’t I…” and then I remember to set up a .gitignore and make a new commit to take out the .DS_Store and put in the .gitignore.You probably already know this, but for those who don’t, git can globally ignore patterns. It’s the first thing I set up after logging in. Honestly wish git just shipped this way out of the box (maybe match .DS_Store by name and some magic bytes?) with a way to disable it. Just for the sake of easier onboarding