There’s clear line between these two and one should never cross that line without very good reason. Version control systems, such as git and SVN, are very popular around the globe and used in most projects. Version control systems allow saving individual changes to files, diffing those changes and ultimately rolling back the work to specific revision. But version control systems should not to be used to store all data your project needs. So what you should put in version control system? At least: Source code files Scripts and other files you need to build software , such as README and LICENSE files Text formatted documentation , such as clang-format settings and .gitignore Tool configuration files All other text files that your project needs Baseline for files in version control is that they are hand written text. So what should not be put in the version control and why? . Each person working with the repository should be able to generate these files with a push of a button — it’s not good idea to put them in version control as they only mess up your history once the generated files change Generated files . This should be clear — build artifacts just do not belong to the version control. Having them there would mean that every time source code changes, all related build artifacts would also be updated. Just do it. Build artifacts DO NOT . Actually this is a bit ambiguous topic. Personally I don’t want to keep the IDE configuration files at least on top of the project repository but instead in some subfolder where people can copy or use a script to set up the repository for their IDE of choice (also using saves you the huzzle ;)). IDE specific configuration files vim . While storing documentation, such as pdfs or excel sheets, in the repository might make sense it does not actually bring any more value than you can rollback to specific version. You cannot diff the changes and see what has been changed and when. If you really need to store binary documents in your repository, at least consider using svn or git with the git-lfs extension to make it a bit less painful. Binary documentation files . This means JAR files and other pre-compiled binaries as well as the 3rd party source code. The build environment should take care of fetching or building the necessary dependencies for you. Using like a dependency manager such as can help you a lot with this. Pre-compiled and source code of 3rd party dependencies right tools gradle . This means tools (executables), images, audio, videos, database files and other files you cannot open with your text editor and read. Sometimes it’s necessary to have some images in the repository but you should always think twice before pushing them. All other binary content To prevent this kind of content ending in to the repository by accident, one should use ignoring of files by their types (such as .gitignore or svn:ignore). Also if you are using git you might want to setup file to be used on all computers you work on. global gitignore If you liked the story, please press the ❤ button below (did you know that you can give more than one clap). Also please feel free to share this story! About me I am Heikki Hellgren, Software Expert and technology enthusiast working at . My interests are in software construction, tools, automatic testing and all the new and cool stuff like AI and autonomous driving. You can follow me on and and check out my for more information. Elektrobit Automotive Medium Twitter website

Twitter

Read My Stories

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

What should be in version control… and what should not.

Too Long; Didn't Read

People Mentioned

Company Mentioned

Heikki Hellgren

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

What should be in version control… and what should not.

Too Long; Didn't Read

People Mentioned

Company Mentioned

Heikki Hellgren

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES