2012-04-27 11 views
64

Qual è la migliore pratica di distribuzione di binari da un progetto github?Qual è la migliore pratica di distribuzione dei binari da un progetto github?

mi viene in mente:

  • Creare una cartella bin del progetto in cui si mantiene una copia dei file binari. Tuttavia, github è pensato per memorizzare il codice sorgente e non i file binari. La memorizzazione di file di grandi dimensioni e che cambiano regolarmente possono essere costosi in quanto spazio disco e larghezza di banda?
  • Carica una copia dei file binari nello github pages del progetto o utilizza un sito Web separato per ospitare i file binari. Tuttavia, ciò non è sempre fattibile e richiede più lavoro (a mano) per mantenere aggiornati i file binari , preferisco che i binari vengano aggiornati automaticamente o con una singola azione .
+0

Questa domanda è su dove ospitare i binari, e fuori tema dato suggerimenti su dove ospitare i file – random

risposta

17

E 'chiaro per me ora che è importante non è per memorizzare i file binari nel progetto github stessa. Pertanto, dovrai memorizzare i binari altrove. Le soluzioni possibili che ho trovato sono:

  • Memorizzare i file binari in un sottomodulo separato (dalores idea). Ha senso memorizzarli nei tuoi progetti github pages, che usi per ospitare il tuo sito web di progetti tramite github.
  • Se si dispone solo di pochi file binari o zip, è possibile caricarli su github tramite Download -> Carica un nuovo file. Questa funzione è abbastanza limitata, tuttavia, non è possibile inserire file in cartelle strutturate.
  • In caso di file jar java, esistono soluzioni come Nexus per la gestione delle librerie.
  • Conservare i binari in un sito completamente separato che ospitate da soli
+6

Perché è importante non memorizzare i binari nel proprio progetto github? –

+0

il tuo codice sorgente è in genere in continuo sviluppo, con un sacco di commit e piccole modifiche tutto il tempo. I binari, d'altro canto, sono generati con versioni stabili del codice che non dovrebbero mai cambiare dopo il rilascio. E per i binari ti piacerebbe avere una directory che elenca tutte le versioni rilasciate, non solo l'ultima versione. È totalmente l'opposto l'uno dell'altro. –

+1

I caricamenti di GitHub sono ora deprecati. Vedere https://github.com/blog/1302-goodbye-uploads – akaihola

2

Che tipo di file binari? I binari devono provenire dalla fonte ad un certo punto, giusto?

Quindi aggiungere il sorgente che crea quei file binari come sottomodulo in git. Quindi, nel processo di compilazione, crea questi binari prima di creare la tua fonte. Il sottomodulo viene mantenuto sincronizzato con una versione specifica della fonte che sai che funziona. Hai anche il vantaggio di poter eseguire il debug più facilmente dal momento che hai la fonte.

A meno che i file binari non siano immagini ecc., Quindi memorizzarli.

Se lo spazio è il problema, utilizzare bitbucket in quanto hanno spazio illimitato.

+0

ho per esempio, una libreria Java (jar) generati da un progetto Java. Ho bisogno di memorizzare questa libreria in modo tale che sia scaricabile per l'utente della libreria senza dover creare autonomamente la libreria. Devo anche memorizzare diverse versioni del jar (1.3.0, 1.3.1, 1.4.0, ecc.) Mentre lo sviluppo continua. –

+1

Per i file jar non è possibile memorizzarlo in nexus e utilizzare Maven per scaricare le dipendenze? Questo è il modo standard di java. Vedi http://stackoverflow.com/questions/3329041/best-practice-to-store-jar-files-in-vcs-svn-git – dalore

+0

Grazie che ha un senso. Quindi, almeno è chiaro che è meglio non memorizzare jars e binari in git stesso, ma usare una soluzione esterna. –

56

A partire dal 11 dicembre 2012 il Downloads feature on GitHub is deprecated. L'articolo Distributing large binaries consiglia di utilizzare un servizio esterno:

Si consiglia Amazon S3 per lo stoccaggio in coppia con CloudFront per servire tramite CDN, o di altri servizi, come SourceForge.


Tuttavia, since 2d July 2013, è ora possibile definire una rilascio.

Rilasci, un flusso di lavoro per il software di spedizione per gli utenti finali.
I rilasci sono oggetti di prima classe con changelog e risorse binarie che presentano una cronologia completa del progetto oltre le risorse Git. Sono accessibili dalla home page di un repository:

homepage

  • Uscite sono accompagnati da note di rilascio e link per scaricare il codice del software o la fonte.
  • In seguito alle convenzioni di molti progetti Git, i rilasci sono legati ai tag Git. Puoi utilizzare un tag esistente o lasciare che i rilasci creino il tag quando viene pubblicato.
  • È inoltre possibile allegare asset binari (come eseguibili compilati, script minificati, documentazione) a una versione. Una volta pubblicati, i dettagli di rilascio e le risorse sono disponibili per chiunque possa visualizzare il repository.

release

+0

"pagine github" è pubblico. "release di github" richiede un account github. :-( –

Problemi correlati