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.
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.
As you should. Because the alternative is just putting it on some team wiki page where they’ll just copy and paste it to their local stuff anyways. It just saves everyone time.
If your whole team uses the same IDE, what’s wrong with commiting things like run configurations and code styles? I agree in general, but a wholesale ban on it is very cargo culty to me. There can be legitimate times to do it.
I elaborated on it below. Your team will grow and shrink. No guarantee that each developer will bring the same IDE. This is especially true for open source projects.
If it works your team, no need to be dogmatic about it. Just be careful about what you put there and agree on a set of sane defaults with your team. Your project should build and run tasks without needing a specific IDE.
Just gitignore that. Same for dot idea and whatever vscode adds, if anything
You can add
.DS Storein your global gitignore at~/config/git/ignoregit 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.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.
I get this but I commit my vscode run configuration and testing env vars.
As you should. Because the alternative is just putting it on some team wiki page where they’ll just copy and paste it to their local stuff anyways. It just saves everyone time.
That’s exactly my thinking.
If your whole team uses the same IDE, what’s wrong with commiting things like run configurations and code styles? I agree in general, but a wholesale ban on it is very cargo culty to me. There can be legitimate times to do it.
I elaborated on it below. Your team will grow and shrink. No guarantee that each developer will bring the same IDE. This is especially true for open source projects.
If it works your team, no need to be dogmatic about it. Just be careful about what you put there and agree on a set of sane defaults with your team. Your project should build and run tasks without needing a specific IDE.