As a rule, you need to add to .gitignore

1. Database. They have their own ways of backing up and using git for this is irrational or even dangerous.
2. Files formed in the process and the result of compiling the project. As a rule, they are assigned folders with names like target/ , output/ , release/ , debug/ . These files can be obtained from the source code, so their versioning does not make sense.
3. Different third-party tools that you put in the same folder with the project. Better yet, simply do not store them in the same folder.
4. Files generated by the test framework, profiler, debugger, etc.
5. The documentation generated from the code is only if you do not generate it into a separate repository through which you then deploy the documentation site.
6. Files created by executing code: logs ( *.log ), work results, etc.
7. Temporary files of your text editor or development environment. Often their name ends with a tilde: *~ .
8. Files created by the operating system, for example thumbs.db , .DS_Store

Worth thinking

1. Large binary files. Especially if they are constantly updated regardless of the version of the code.

As a rule, you can not ignore, you need to save

1. Ignore all the git configuration files. This is the .git folder itself (in any case, it cannot be added to the index) and other files: .gitattributes , .gitignore .
2. Files that define the structure of the project. As a rule, they are created by the development environment. Their loss at best threatens you with the loss of time to reorganize the project in the IDE, at worst - the need to manually restore the connection.
3. Actually, the code and related resources.

In addition to the answer @Nick Volynkin

Required OS system files and backups

 ### Linux template *~ # KDE directory preferences .directory # MacOS .DS_Store .AppleDouble .LSOverride 

IDE files themselves (if you are working on LAN)

 ### NetBeans template nbproject/private/ build/ nbbuild/ dist/ nbdist/ nbactions.xml nb-configuration.xml .nb-gradle/ ### JetBrains template # Covers JetBrains IDEs: IntelliJ, RubyMine, PhpStorm, AppCode, PyCharm, CLion, Android Studio *.iml ## Directory-based project format: .idea/ 

Different plugins

 ## Plugin-specific files: # IntelliJ /out/ # mpeltonen/sbt-idea plugin .idea_modules/ # JIRA plugin atlassian-ide-plugin.xml # Crashlytics plugin (for Android Studio and IntelliJ) com_crashlytics_export_strings.xml crashlytics.properties crashlytics-build.properties 

File system

 # Thumbnails ._* # Files that might appear in the root of a volume .DocumentRevisions-V100 .fseventsd .Spotlight-V100 .TemporaryItems .Trashes .VolumeIcon.icns # Directories potentially created on remote AFP share .AppleDB .AppleDesktop Network Trash Folder Temporary Items .apdisk 

Addition

From @Timofey Bondarev comment

It turns out there is a convenient site for generating .gitignore - https://www.gitignore.io

And now I’ve got in and give an unpopular opinion.

Do not dare copy-paste "standard" .gitignore. You must understand each line, otherwise you will sink into the stream of WTF.

What NOT to add to the .gitignore repository

1. Garbage generated by your operating system.

All this should be in the global .gitignore, and not copy-paste to each repository. If your operating system is crap in the file system, then deal with it at the system level, and not every repository you work with.

Files that need to be considered three times

1. IDE files and everything connected to it. You need to understand what files are and what for. For the sake of example:

   1. R # + C #: MySolution.sln.DotSettings - the "command" settings for the project, MySolution.sln.DotSettings.user - the "personal" settings for the project (there are still "system", they are in another place). It is necessary not only to make sure that the correct file is signed, but also that the changed settings fall into the necessary file, otherwise there will be disagreements with the command.

   2. IDEA: there are acidic manuals on what files to store and why. You can't just ignore .idea/ , because the project settings will fall off. You can’t just leave and leave .idea/ , because your personal ways will get to everyone and give birth to conflicts. In other environments, files can be from zero to infinity, get ready to explore your tool.

2. Generated during assembly files. There are different traditions in different languages ​​and environments, and serious disputes flare up around individual files. For the sake of example:

   1. Composer + PHP: Keep or not store composer.lock - depends on the priorities of the command, library or application you are developing, and on personal tastes. You need to be well aware of the pros and cons of finding a file in the repository.

   2. T4 + C #: It is common in C # to store code generation output so that you can easily build a project. In this case, you can customize the assembly so that code generation starts when you build it, but this is not possible for all scripts. It should be noted that non-T4 code generation usually falls into Output, and therefore is ignored. In other languages ​​and environments more often they profess an ideology that the output of code generation will never commit.

3. Binary Git disgustingly works with binaries, unlike backward VCS like SVN. The repository grows prohibitively if files are updated frequently.

   1. If you rarely update files and they are small, you can put the files in place.

   2. Otherwise, it is better to hide files in some other place. There are both universal crutches for Git (Git LFS), and language and environment-specific tools (personal NuGet server).

   3. If you can use NuGet, Composer, CPAN, Lein, Maven, then use. Binary dependencies should be there.

Ideal

You should strive to ensure that the repository has the minimum possible number of files, which are enough to build the entire project with absolutely no interference and configuration of anything.

Often the ideal is unattainable. So look for a compromise.