1

I have a lot of small projects, and while their source code is backed up and tracked with git, I don't know what to do with the rest of the files associated with a project.

These consist of small text files, some images, maybe a prototype or proof of concept, etc. They're not necessary to build or deploy, but I need them while working on the project.

It's not really documentation, but rather todo lists, bugs to be fixed, a few screenshots, that sort of thing. As I said before, they're small projects so I don't think I should create a wiki/bugtracker for each one, especially since I'm the only developer :)

I backup these, but I feel they could benefit from git as well (in another repository). I've sorted these files in three main folders, "current", "abandoned", and "finished".

Should I use git and just git mv the files when the project is finished or abandoned ? I'm a bit new to git, and I don't know how well tools "like" whole folders that move.

If you have a better way of keeping track of those files, I'm interested. It's probably too broad for a SE question, though.

marked as duplicate by gnat, GlenH7, gbjbaanb, user40980, Kilian Foth Mar 5 '14 at 8:34

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

8

Any project files which are needed for the production system (the application code + tests to ensure requirements compliance, configuration, cron jobs, and anything else which is part of your process) and which cannot be generated automatically (even using wget) should be in version control. Everything else can be ignored.

  • What do you mean by ignore ? If I'm working on something I want the both the code and the notes/docs associated with it. – Manu Mar 4 '14 at 15:31
  • 3
    Documentation which is necessary for anyone who has to work with the project (developers, sysadmins, users, support personnel, etc.) is needed for the production system. QED :) – l0b0 Mar 4 '14 at 15:34
-2

If the build fails without them, add to master. If the build passes but you need these files for whatever reason, add them in another branch like "resources". If you don't need them any more, just remove them.

  • 1
    I disagree, files such as documentation are generally not needed for a build to succeed. However, documentation is for a version of software and needs to be updated as the code is updated (e.g. new features). Therefor, at a minimum, documentation must be kept with the code. Other resources such as icons or other binary resources included in an executable generally fall into the "cannot compile without it" category and are also included with the code in master. – user22815 Mar 4 '14 at 15:49
  • 4
    This is a poor use case for a branch, IMO. – BrandonV Mar 4 '14 at 15:53
  • @JohnGaughan: Documentation should be part of the build as the product cannot(shouldn't) exist without documentation. Brandon: care to explain why? – Silviu Burcea Mar 5 '14 at 8:11
  • @SilviuBurcea this depends on the documentation and the language. Sure, something like JavaDoc or Doxygen is a build product, but not all languages have an automated documentation tool (although Doxygen is extensible). Besides, not all documentation is code documentation. What about schema diagrams that are not auto-generated but are tied to a specific version of software as it evolves? Maybe version 2.0 introduces a schema change so that version needs different diagrams. Keeping them in a branch makes it more difficult to associate them together. – user22815 Mar 5 '14 at 15:05
  • I have seen a pattern in the github projects, a /docs folder, I'm using it too and I keep it in the master branch. Other resources like generated reports while testing or any other similar things should be removed, not everything not related with code, maybe I wasn't clear enough in my answer ... – Silviu Burcea Mar 5 '14 at 15:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.