_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_ * [_Text formatted_](https://hackernoon.com/say-yes-to-markdown-no-to-ms-word-be4692e7a8cd) _documentation_, such as README and LICENSE files * _Tool configuration files_, such as clang-format settings and .gitignore * _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? * _Generated files_. 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 * _Build artifacts_. 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 NOT** do it. * _IDE specific configuration files_. 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 [vim](https://hackernoon.com/my-vim-crash-course-pt-2-e51592693f91) saves you the huzzle ;)). * _Binary documentation files_. 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. * _Pre-compiled and source code of 3rd party dependencies_. 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 [right tools](https://hackernoon.com/saving-and-%EF%B8%8F-with-the-right-tooling-for-developers-e07f4be67a5) like a dependency manager such as [gradle](https://gradle.org/) can help you a lot with this. * _All other binary content_. 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. 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 [global gitignore](https://github.com/drodil/dotfiles/blob/master/.gitignore_global) file to be used on all computers you work on. 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 [Elektrobit Automotive](https://www.elektrobit.com/). 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 [Medium](https://medium.com/@drodil) and [Twitter](https://twitter.com/dr0dil) and check out my [website](https://drodil.kapsi.fi/) for more information.