You should push your (IDE) config to version control — and here is why

Many gitignore files are full of ignores, for our IDEs and editors. Is it Visual Studio Code, IntelliJ, or even vim? But why are we excluding all files, many even consider it as a bad practice having them in the project at all!

Make setup for new devs easier

The first and maybe most important thing is that, especially in a corporate setup, you will have a common tooling along to developers. So instead of creating a gigantic guide on how to set up the project properly, ship the config with the project.

So project setup just becomes checkout, open and go!

A very prominent example, coming from the IntelliJ world, is excluding files for index generation etc. Especially for larger projects or in serverless context, this makes the life of devs a lot easier when the configuration is already there.

Distribute changes to set up easily

Not only for new devs but also for ones already onboarded, working on the project for a long time can benefit from configuration being shipped with the project. Assuming you just discovered a new setting for the project that makes life easier, distributing is as simple as commit. No longer sharing in meetings, chats or just forgetting about it at all.

This also means when a setting breaks something, you can figure out why exactly it is now failing, was it happening after a specific project config change? Revert, try again.

Not all files are equally important

Some configuration is just a matter of user preference and should not be versioned. So, most important is to agree on what is considered important for the project. A standard, which is simply a matter of preference.

For example, IntelliJ already suggests a gitignore File when setting up git initially. It is definitely a good idea to carefully review it and extend it. Most plugins are not considered for the gitignore, but may have project-specific settings. So take these cases into account as well.

A really great example is the AWS plugin for JetBrains products. It absolutely makes sense to add it to the repository, so developers can use the right AWS account for, e.g., SAM invocations for executing lambdas locally. On the other hand, the plugin for the discord rich presence is something you probably don't want to share with your team.

So keep the config clutter-free, but add the really valuable pieces to the repository. Every so often it is hard to find a balance, especially in larger projects or variations in tooling stack on the developer's machine. The more diverse your tooling landscape is, the harder it gets. Just let's assume you are developing Java together with devs using Visual Studio Code, NetBeans, Eclipse and IntelliJ. It will definitely become more challenging compared to all users just utilizing IntelliJ for development.

Track your IDE settings independently as well

Many tools provide some kind of settings sync, which many people out that are not aware of, but make setting up new devices a breeze.

The most obvious advantage is reducing the time to set up new machines, but already provides you with a peace of mind. This allows you to tweak your settings without fear of having to reproduce it or lose your productivity when forgetting about a specific setting.

I try to spotlight the most important services/possibilities to sync your settings, depending on your tooling. If you feel like any significant one is missing, feel free to add a comment.

Managed Services

Visual Studio Code provides the so-called Settings Sync, where Microsoft stores the settings for you. All you need is a Microsoft or GitHub account. It is completely free of charge and works pretty well.

For JetBrains Products, there is a plugin called IDE Settings Sync. You will need a JetBrains subscription so you can use their service. As long as you are having a license for one of their products, you are good to go.

DIY Approach

What is also possible is, putting your settings folders into a git repository. This basically works with every editor/IDE that stores the configuration files somewhere.

For vim, you can locate the configuration in your dotfiles, allowing you to use the regular dot file manager utilities.

The greatest advantage is you keep complete control over your configuration files and are independent of the providers. Of course, as everything in life, this comes with a cost – You probably guessed it: version conflicts and updating is not done automatically, and you are in charge.

For IntelliJ, there is also a plugin, automating the settings, they call it Settings Repository.

But what if things crash?

It can happen that you have “un-mergable” configuration files, in these cases it is a good practice to just use the latest one.

This rarely happens in practice, just don't waste too much time on these situations. Of course, it also requires a bit of courage from developers working on the project. If something has been checked in that shouldn't, learn from it, extend the gitignore accordingly and go on with life.

Conclusion

Version your config! If it is on the project repository and for yourself. It makes sense and provides great benefits, coming at nearly no cost at all!

I have been on the side “get the sh*t out of my repository” for a very long time. But with time comes more experience, more complex projects. After struggling with the mentioned problems, and rethinking my opinions on this topic while searching for a way to make the workflow of my teams better led to a pretty solid set of best practices.

What's your opinion on versioning the configuration? Do you already do it or plan to do after reading the post?