60

It would be nice to have a more or less complete list over what files and/or directories that shouldn't (in most cases) be under source control. What do you think should be excluded?

Suggestion so far:

In general

  • Config files with sensitive information (passwords, private keys etc.)
  • Thumbs.db, .DS_Store and desktop.ini
  • Editor backups: *~ (emacs)
  • Generated files (for instance DoxyGen output)

C#

  • bin\*
  • obj\*
  • *.exe

Visual Studio

  • *.suo
  • *.ncb
  • *.user
  • *.aps
  • *.cachefile
  • *.backup
  • _UpgradeReport_Files

Java

  • *.class

Eclipse

I don't know, and this is what I'm looking for right now :-)

Python

  • *.pyc

Temporary files - .*.sw? - *~

l3dx
  • 2,930
  • 6
  • 33
  • 43
  • Possible duplicate? http://stackoverflow.com/questions/85353/best-general-svn-ignore-pattern – Bob King Aug 13 '09 at 19:03
  • You can keep anything in source control, depending on your problem domain. This is not a real question. –  Aug 13 '09 at 19:04
  • Yes you can, but most people have something they want to ignore. I thought it was a good idea to make a list of the most common. – l3dx Aug 13 '09 at 19:08
  • and I agree, should perhaps be community wiki – l3dx Aug 13 '09 at 19:09
  • 7
    How about asking for clarification, instead of closing the question? – JW. Aug 13 '09 at 19:10
  • 37
    Wow, closing is a little harsh. Totally legitimate question. – Jonathon Watney Aug 13 '09 at 19:15
  • 3
    This sounds like a real question to me. Voting to re-open – marcgg Aug 13 '09 at 19:16
  • @Arnis L: how is this not a question? – John Saunders Aug 13 '09 at 23:31
  • 2
    I'm not going to eat all the downvotes for saying it, but I think the conventional wisdom of never checking in generated DLL's and EXE's is usually based on cargo cult "best practices" without any real backing. It's often useful and rarely harmful. – Jon Galloway Aug 14 '09 at 00:43
  • 2
    @Jon: I'm curious now- how is it useful? Why can't you just check out the revision and simply recompile to generate all those dll's and exe's? – skybluecodeflier Jun 28 '11 at 23:50
  • 2
    @skybluecodefier I've personally seen several times where the build didn't actually work at precisely the time when there was a production emergency. The build should always work, but sometimes doesn't, and there's real cost to not having the binaries. What is the cost to actually having them available? – Jon Galloway Jun 28 '11 at 23:58
  • @l3dx have you seen https://github.com/github/gitignore? I mention a little more about it in my answer at the bottom. – Ehtesh Choudhury May 23 '17 at 21:38
  • @Jon The cost is that they tend to get out of sync with the source they’re generated from, so you can’t necessarily be sure what source corresponds to the code you’re deploying. I generally advise making sure your build process is airtight and repeatable, and then removing generated files from the repo. – Marnen Laibow-Koser Mar 27 '19 at 15:12

24 Answers24

43

Anything that is generated. Binary, bytecode, code/documents generated from XML.

From my commenters, exclude:

  • Anything generated by the build, including code documentations (doxygen, javadoc, pydoc, etc.)

But include:

  • 3rd party libraries that you don't have the source for OR don't build.

FWIW, at my work for a very large project, we have the following under ClearCase:

  • All original code
  • Qt source AND built debug/release
  • (Terribly outdated) specs

We do not have built modules for our software. A complete binary is distributed every couple weeks with the latest updates.

Corey D
  • 4,689
  • 4
  • 25
  • 33
  • 3
    JavaDoc/Doxygen/etc output is included in this. – Thomas Owens Aug 13 '09 at 19:03
  • It may be very useful though. Consider a big repository, with many files shared accross multiple application. If I decide to work on one of this app, I'll need to recompile everything once, before my fix is compiled. It could take a long time unless someone provide me the object file package. The repository could provide all of them. – yves Baumes Aug 13 '09 at 20:04
  • 2
    @yves: but then if you have both compiled and source versions of the same thing, they could get out of sync. What if someone updates some code and checks it in, but forgets to compile it? You could be using stale compiled code from the repository and it could lead to mysterious bugs. If compiling time is such a big issue, you could have a separate store for compiled object files. – David Z Aug 13 '09 at 20:15
  • @David: true.But you know , people have to be responsible about what they do. For isntance, on a normal respository (without object files) they must not forget to commit every single source files they modified, otherwise it could break the build – yves Baumes Aug 13 '09 at 20:23
  • source control is to hold and track revisions of "source". Putting compiled files on source control may speed up a situation but can cause confusion in multi-user environments and cause more troubleshooting problems then it's worth. – Nick Aug 13 '09 at 20:44
  • 3
    You should change this to say anything that is going to be generated by the build. The output of a T4 Template will probably not be generated by the build, and so should be checked in. – John Saunders Aug 13 '09 at 23:21
  • 1
    Files that are generated by specialist tools are an exception: http://stackoverflow.com/questions/1273921/what-should-not-be-under-source-control/1275259#1275259. – Paul Biggar Aug 13 '09 at 23:40
  • This answer is very obvious, of course it's the temp/autogenerated stuff. *Which* files commonly fall into this category? – MGOwen Aug 13 '09 at 23:57
  • 7
    Actually, it's quite legitimate to also put third party libraries under source control especially if you don't have the sources for them. – hookenz Aug 14 '09 at 00:15
  • 1
    You need to qualify your answer a bit further! I agree with Matt, binary third party dependencies are definitely important to put in source control. – Ash Aug 14 '09 at 02:40
  • Sometimes it is necessary to put binaries and other things that can be generated under version control. / Folks have already mentioned third party libraries. / Another: generated stuff that is dependent on tools that are not version controlled, like libraries, linkers. / I sometimes version control such generated stuff, and have build tests that check that we can regenerate. / Sometimes the generated stuff is text, sometimes binary. – Krazy Glew Oct 23 '15 at 21:34
  • By the way, the different terms "Source Code Control" and "Version Control" provide insight. In the beginning, version control tools like SCCS and RCS could only handle text well, hence the emphasis on source code (text) control. But stuff that is not text needs to have its history tracked. / If your tools cannot do version control of arbitrary stuff, then you need better tools!!!! – Krazy Glew Oct 23 '15 at 21:40
18

OS specific files, generated by their file browsers such as Thumbs.db and .DS_Store

pgb
  • 24,813
  • 12
  • 83
  • 113
15

Some other Visual Studio typical files/folders are

*.cachefile 
*.backup 
_UpgradeReport_Files

My tortoise global ignore pattern for example looks like this

bin obj *.suo *.user *.cachefile *.backup _UpgradeReport_Files
apparat
  • 1,930
  • 2
  • 21
  • 34
11

files that get built should not be checked in

pmeerw
  • 425
  • 3
  • 8
  • 3
    Except if you are deploying them for release. For example, our wix project builds an MSI file, and even though we tag all of our source code and tools (3rd party or otherwise) it's very useful, sometimes critical to have the MSI stored in our repository along with the code. Sure you could back it up somewhere else, but my question would be why? – si618 Aug 14 '09 at 00:40
  • Agreed, our CRUD partial classes are checked in to comply with SOX laws. – RiddlerDev Aug 14 '09 at 00:51
  • Answer too generic. OP asking for *which* files specifically. – MGOwen Aug 17 '09 at 01:54
7

Like Corey D has said anything that is generated, specifically anything that is generated by the build process and development environment are good candidates. For instance:

  • Binaries and installers
  • Bytecode and archives
  • Documents generated from XML and code
  • Code generated by templates and code generators
  • IDE settings files
  • Backup files generated by your IDE or editor

Some exceptions to the above could be:

  • Images and video
  • Third party libraries
  • Team specific IDE settings files

Take third party libraries, if you need to ship or your build depends on a third party library it wouldn't be unreasonable to put it under source control, especially if you don't have the source. Also consider some source control systems aren't very efficient at storing binary blobs and you probably will not be able to take advantage of the systems diff tools for those files.

Paul also makes a great comment about generated files and you should check out his answer:

Basically, if you can't reasonably expect a developer to have the exact version of the exact tool they need, there is a case for putting the generated files in version control.

With all that being said ultimately you'll need to consider what you put under source control on a case by case basis. Defining a hard list of what and what not to put under it will only work for some and only probably for so long. And of course the more files you add to source control the longer it will take to update your working copy.

Community
  • 1
  • 1
Jonathon Watney
  • 20,248
  • 9
  • 38
  • 40
  • 3
    Sometimes you build third party libraries from their source, in which case you probably don't check in the binaries. But if you don't build from source, then by all means, check in the binaries. – JeffH Aug 13 '09 at 19:12
  • +1 By all means if you can build third party libraries from source then go for it. – Jonathon Watney Aug 13 '09 at 19:18
  • Seems simple to me. If you generate the images and libraries and whatever from what is under version control, don't check them in. If you don't, then at least consider checking them in. – David Thornley Aug 13 '09 at 19:34
  • In two of your cases, they should be checked in unless generated by the build: "Documents generated from XML and code", and "Code generated by templates and code generators". – John Saunders Aug 13 '09 at 23:24
  • 1
    @John: Even in those cases, there are exceptions. See http://stackoverflow.com/questions/1273921/what-should-not-be-under-source-control/1275259#1275259. – Paul Biggar Aug 13 '09 at 23:39
7

I would approach the problem a different way; what things should be included in source control? You should only source control those files that:

  • ( need revision history OR are created outside of your build but are part of the build, install, or media ) AND
  • can't be generated by the build process you control AND
  • are common to all users that build the product (no user config)

The list includes things like:

  • source files
  • make, project, and solution files
  • other build tool configuration files (not user related)
  • 3rd party libraries
  • pre-built files that go on the media like PDFs & documents
  • documentation
  • images, videos, sounds
  • description files like WSDL, XSL

Sometimes a build output can be a build input. For example, an obfuscation rename file may be an output and an input to keep the same renaming scheme. In this case, use the checked-in file as the build input and put the output in a different file. After the build, check out the input file and copy the output file into it and check it in.

The problem with using an exclusion list is that you will never know all the right exclusions and might end up source controlling something that shouldn't be source controlled.

Ed Greaves
  • 4,807
  • 2
  • 22
  • 19
6

Anything that can be generated by the IDE, build process or binary executable process.

LiraNuna
  • 64,916
  • 15
  • 117
  • 140
  • What about things that can be generated, but are **not** generated? The output of running one of the single file generator "custom tools" is only generated when requested, or when the source document changes. It will not be generated by the build. – John Saunders Aug 13 '09 at 23:22
  • 'or binary executable process' - includes Doxygen output and the like. – LiraNuna Aug 15 '09 at 00:25
  • 1
    @John: If the custom tools are generated every time there's a checkin, I'm not sure there's a savings over generating at request. If they aren't, there's a danger of stale tools. I wouldn't want to have them checked in. – David Thornley Aug 20 '09 at 17:58
6

An exception:

4 or 5 different answers have said that generated files should not go under source control. Thats not quite true.

Files generated by specialist tools may belong in source control, especially if particular versions of those tools are necessary.

Examples:

  • parsers generated by bison/yacc/antlr,
  • autotools files such as configure or Makefile.in, created by autoconf, automake, libtool etc,
  • translation or localization files,
  • files may be generated by expensive tools, and it might be cheaper to only install them on a few machines.

Basically, if you can't reasonably expect a developer to have the exact version of the exact tool they need, there is a case for putting the generated files in version control.

This exception is discussed by the svn guys in their best practices talk.

Paul Biggar
  • 27,579
  • 21
  • 99
  • 152
  • 1
    you can't, but you _definitely_ should. Having different versions of development tools in your team is a good first step toward madness. – Stefano Borini Aug 13 '09 at 23:37
  • @Stefano: Well, consider an open source project, where the particular version of bison the developer has installed varies depending on the distribution. In fact, our autotools files randomly get regenerated at times. – Paul Biggar Aug 14 '09 at 00:20
  • 1
    @Paul: this is a potential source of hard-to-find, hard-to-reproduce bugs. Of course I am a bit extremist (slight differences oftentimes are irrelevant), but you should strive for a uniform, well defined development environment and runtime. – Stefano Borini Aug 14 '09 at 12:33
  • 2
    @Stefano: It is a source of random bugs if its **not** in source control. Because configure and Makefile.in are in source control, we can see when they get regenerated, and *avoid* random bugs. There are many cases where you simply cannot mandate the tools the developer uses, as much as you'd like to. – Paul Biggar Aug 14 '09 at 12:52
  • An example of tools on a few machines is often the FPGA tools (for chip design) aren't on the software team's machine. – Brian Carlton Oct 30 '09 at 20:30
  • On windows you can use a Chocolatey packages.config file ( https://chocolatey.github.io/usage.html#the-packagesconfig-file ) to enforce exact tool versions for developers. I don't know much about tool/package management on linux, but wouldn't something like this work: https://stackoverflow.com/a/10123093/1698736 ? – cowlinator Apr 25 '18 at 00:05
5

Temp files from editors.

.*.sw?
*~

etc.

John Hyland
  • 6,855
  • 28
  • 32
4

desktop.ini is another windows file I've seen sneak in.

Jason Berry
  • 2,469
  • 1
  • 17
  • 21
3

Config files that contain passwords or any other sensitive information.

John Hyland
  • 6,855
  • 28
  • 32
3

Actual config files such a web.config in asp.net because people can have different settings. Usually the way I handle this is by having a web.config.template that is on SVN. People get it, make the changes they want and rename it as web.config.

Aside from this and what you said, be careful of sensitive files containing passwords (for instance).

Avoid all the annoying files generated by Windows (thumb) or Mac OS (.ds_store)

marcgg
  • 65,020
  • 52
  • 178
  • 231
2

*.bak produced by WinMerge.

DeadHead
  • 2,251
  • 16
  • 16
Sam Harwell
  • 97,721
  • 20
  • 209
  • 280
2

additionally:

Visual Studio

  • *.ncb
ufukgun
  • 6,889
  • 8
  • 33
  • 55
2

The best way I've found to think about it is as follows:

Pretend you've got a brand-new, store-bought computer. You install the OS and updates; you install all your development tools including the source control client; you create an empty directory to be the root of your local sources; you do a "get latest" or whatever your source control system calls it to fetch out clean copies of the release you want to build; you then run the build (fetched from source control), and everything builds.

This thought process tells you why certain files have to be in source control: all of those necessary for the build to work on a clean system. This includes .designer.cs files, the outputs of T4 templates, and any other artifact that the build will not create.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
1

Temp files, config for anything other than global development and sensitive information

Codebeef
  • 43,508
  • 23
  • 86
  • 119
  • Config files that are specific to your environment, ie. when using ANT, the build script is under source control, but properties files loaded by the script are not – Ryan McIlmoyl Aug 13 '09 at 19:32
1

Things that don't go into source control come in 3 classes

  1. Things totally unrelated to the project (obviously)
  2. Things that can be found on installation media, and are never changed (eg: 3rd-party APIs).
  3. Things that can be mechanically generated, via your build process, from things that are in source control (or from things in class 2).
T.E.D.
  • 44,016
  • 10
  • 73
  • 134
  • 7
    We check in 3rd party JARs so that when we go back to a previous version in the repository, we have the JARs that were distributed with that version of the software. – Thomas Owens Aug 13 '09 at 19:24
  • 1
    Yeah, I'm going to have to disagree with #2. – Imagist Aug 13 '09 at 20:01
  • I don't agree with point 3 in all cases, see http://stackoverflow.com/questions/1273921/what-should-not-be-under-source-control/1275259#1275259. – Paul Biggar Aug 13 '09 at 23:38
  • @Thomas: If you can keep the installer for those JARs, you should just keep that around instead. If you can't, then it doesn't violate #2. – T.E.D. Aug 14 '09 at 13:47
0

Whatever the language :

  • cache files
  • generally, imported files should not either (like images uploaded by users, on a web application)
  • temporary files ; even the ones generated by your OS (like thumbs.db under windows) or IDE
  • config files with passwords ? Depends on who has access to the repository

And for those who don't know about it : svn:ignore is great!

Pascal MARTIN
  • 395,085
  • 80
  • 655
  • 663
  • I'm editing my git-ignore list, and that's why I came up with this question. :-) – l3dx Aug 13 '09 at 19:05
  • Note that if your editing .gitignore, you might want to expand your question to 'what goes in a project's .gitignore, and what belongs in my global .gitignore?' For example, you probably want *~ to be globally ignored, since backups generated by your editor are in no way related to your project. – William Pursell Aug 13 '09 at 20:26
  • I'm not only interested in .gitignore :) I use other SCM systems as well, and just started searching for a list of commnon files to exclude – l3dx Aug 14 '09 at 06:04
0

If you have a runtime environment for your code (e.g. dependency libraries, specific compiler versions etc.) do not put the packages into the source control. My approach is brutal, but effective. I commit a makefile, whose role is to downloads (via wget) the stuff, unpack it, and build my runtime environment.

Stefano Borini
  • 138,652
  • 96
  • 297
  • 431
0

I have a particular .c file that does not go in source control.

The rule is nothing in source control that is generated during the build process.

The only known exception is if a tool requires an older version of itself to build (bootstrap problem). In that case you will need a known good bootstrap copy in source control so you can build from blank.

Joshua
  • 40,822
  • 8
  • 72
  • 132
0

Going out on a limb here, but I believe that if you use task lists in Visual Studio, they are kept in the .suo file. This may not be a reason to keep them in source control, but it is a reason to keep a backup somewhere, just in case...

Benjol
  • 63,995
  • 54
  • 186
  • 268
0

A lot of time has passed since this question was asked, and I think a lot of the answers, while relevant, don't have hard details on .gitignore on a per language or IDE level.

Github came out with a very useful, community collaborated list of .gitignore files for all sorts of projects and IDEs that is worth taking a look.

Here's a link to that git repo: https://github.com/github/gitignore

To answer the question, here are the related examples for:

There are also OS-specific .gitignore files. Following:

So, assuming you're running Windows and using Eclipse, you can just concatenate Eclipse.gitignore and Windows.gitignore to a .gitignore file in the top level directory of your project. Very nifty stuff.

Don't forget to add the .gitignore to your repo and commit it!

Chances are, your IDE already handles this for you. Visual Studio does anyway.

And for the .gitignore files, If you see any files or patterns missing in a particular .gitignore, you can open a PR on that file with the proposed change. Take a look at the commit and pull request trackers for ideas.

Ehtesh Choudhury
  • 7,452
  • 5
  • 42
  • 48
  • Your project's `.gitignore` file should only contain project-specific exclusions. Exclusions that are due to your local environment (e.g. `*~` [editor-specific] or `Thumbs.db` [OS]) should go in `.git/info/excludes` (see https://help.github.com/articles/ignoring-files/) or better yet in a file in your home directory pointed to by the `gitignore.global` config property. – Marnen Laibow-Koser May 17 '18 at 19:54
0

I am always using www.gitignore.io to generate a proper one .ignore file.

Jacek Krawczyk
  • 2,083
  • 1
  • 19
  • 25
-1

Opinion: everything can be in source control, if you need to, unless it brings significant repository overhead such as frequently changing or large blobs.

3rd party binaries, hard-to-generate (in terms of time) generated files to speed up your deployment process, all are ok.

The main purpose of source control is to match one coherent system state to a revision number. If it would be possible, I'd freeze the entire universe with the code - build tools and the target operating system.

Pavel Radzivilovsky
  • 18,794
  • 5
  • 57
  • 67
  • 2
    -1 I'm sorry bro but I hate having config files (that is, for your own dev environment... not for your application) and in house dlls and other files you generate every time you compile in source control. It makes it much more tedious to quickly look through 'real' changes with these constantly being updated. I don't give out -1's much but I'm currently working with someone who does this and it constantly causes conflicts with binaries and the less experienced programmers come to me to fix them. – Brandon Moore Feb 03 '12 at 16:55
  • Downvoting. If you have a decent build system and dependency manager, there's generally no reason to put generated files and 3rd-party binaries in your VCS repo. – Marnen Laibow-Koser May 17 '18 at 19:56