Pratica standard per pubblicare e controllare il codice sorgente di un singolo file? [chiuso]

Hai problemi con questa domanda perché non stai pensando alle cose giuste. Il controllo del codice sorgente è uno strumento, non è un mezzo per un fine. Quali sono i tuoi piani lungo la strada?

Vuoi avere un toolkit di molti script in cui le persone possono usare qualsiasi o tutti i tuoi pacchetti per, ad esempio, l'elaborazione audio? Quindi raggruppali nel repository AudioMiscellanea.

Vuoi che questo progetto sia autonomo, in cui potrebbe potenzialmente essere refactored in più file e aggiungere funzionalità e altra complessità? Dagli il suo repository.

In breve: pensa ai tuoi obiettivi e quale paradigma si adatta meglio a questi obiettivi, piuttosto che "qual è la migliore pratica".

I repository Git sono incredibilmente facili da configurare. Sposta il tuo file in una directory a parte, esegui git init e inizia a godere del controllo della versione. Non c'è niente di negativo in questo, tranne che si finisce con un sacco di repository. Se vuoi condividere quel repository su GitHub o Bitbucket, basta farlo - dopotutto, i repository pubblici sono gratuiti.

L'idea di avere un grande repository che contenga molti progetti minori è purtroppo abbastanza comune. Quando si lavora con SVN, questa era in realtà l'opzione più sensata, ma con Git, questo non ha posto: tenere separati gli elementi separati. Soprattutto, l'utilizzo di repository diversi per diversi progetti mantiene la storia abbastanza pulita e rende facile per gli altri l'utilizzo dello script che desiderano senza dover gestire l'altro cruft che si è insinuato nel repository catch-all.

Penso che Github Gists sarebbe perfetto per questo 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.

Ha persino un'API per ottenere, pubblicare, modificare i tuoi file / snippet.