I often want to publish some useful standalone script - e.g., a matlab script which converts flac files into wav files. If it were a big project I would immediately place it in Github, however it seems weird to make a repository for a single file. I could group this script with other scripts of the same subject (e.g., "audio" scripts), however that would make for a repository for miscellanea. I want other developers to use these files and also improve them. Should I simply go with the repository-of-one-file option or is there a more standard practice?
-
3Take a look at Github Gists – raptortech97 Dec 17 '14 at 22:50
-
Take a look at gitlab.com/esr/src Created by a well known programmer, modern "ui" – 0fnt Jul 28 '16 at 11:12
3 Answers
You're having trouble with this question because you're not thinking about the right things. Source control is a tool, it's not a means to an end. What are your plans down the road?
Do you want to have a toolkit of many scripts where people can use any or all of your package for, say, audio processing? Then group them together in the AudioMiscellanea repository.
Do you want to have this project be standalone, where it could potentially be refactored into multiple files and have features and other complexity be added to it? Then give it it's own repository.
In short: Think about your goals, and which paradigm best suits those goals, rather than "what's the best practice".

- 7,590
- 9
- 37
- 67
-
Thanks! I am still not sure how to well-define my goal though - basically, I am in academia, and I have a blog in which I write about the research I conduct. A lot of times the posts are simply about a script that performs a mundane task which a lot of my peers need but never get around to writing. I used to simply place the script in the blog post, but I wish to switch to something like github so as to allow people to improve my code. For this specific scenario, which choice would you recommend? – olamundo Dec 18 '14 at 10:23
Git repos are incredibly easy to set up. Move your file into a directory of its own, run git init
, and start enjoying version control. There's no downside to doing this, except that you end up with a lot of repos. If you want to share that repo on GitHub or Bitbucket, just do so – after all, public repos are free.
The idea to have one big repo that contains many smaller projects is unfortunately quite common. When working with SVN, that was actually the most sane option – but with Git, this has no place: please keep separate things separate. Especially, using different repos for different projects keeps the history fairly clean, and makes it easy for other people to use the script they want without having to deal with the other cruft that crept into your catch-all repository.

- 132,749
- 27
- 279
- 375
I think Github Gists would be a perfect fit for this scenario.
Gist is a simple way to share snippets and pastes with others. All gists are Git repositories, so they are automatically versioned, forkable and usable from Git.
It even has an API to get,post, edit your files/snippets.

- 246
- 1
- 4