Come evitiamo i file di sviluppo nella versione?

When we make a release, that release contains not only the actual release files but also contains all the meta and testing stuff. This happens because GitHub's way of creating releases is to simply ZIP up a snapshot of a branch.

Questo non è del tutto corretto, per quanto posso dire. In GitHub, una release è un tag che punta a uno specifico commit - e mentre GitHub fornisce un'opzione per scaricare il codice sorgente corrispondente a questo tag come file .zip dalla pagina di rilascio, questo non è il modo previsto per distribuire l'applicazione.

Invece, ci si aspetta che allega una o più risorse - che significa preparare i pacchetti da soli (o usare uno script di build / release) e collegarli tramite l'API GitHub o manualmente dalla pagina web di creazione del rilascio.

Il tag stesso e l'opzione per scaricare le fonti sono lì solo se si desidera ispezionare il codice sorgente nel punto di quel rilascio specifico. Non sono pensati per essere consumabili dall'utente finale - pensa a cosa succederebbe se il progetto fosse scritto in un linguaggio compilato, come C # o Java. In tal caso, l'utente non sarebbe nemmeno in grado di eseguire la versione, dal momento che le risorse di build non sono presenti nel repository.

Stai confondendo il tuo codice sorgente con i risultati finali.

Tutto il codice sorgente, tutta la documentazione, tutto il codice di prova, dovrebbero essere tutti nel repository git. E poi dovresti avere uno script di build che estrae tutti i deliverable in una directory (ovviamente con sottodirectory), e che viene spedito al cliente.

Diciamo che per una nuova funzione il tuo deliverable dovrebbe contenere un altro file python che implementa quella funzione, e hai due script di test e quattro file con i dati di test. Si aggiorna lo script creando il deliverable aggiungendo un comando per copiare quel file python nel deliverable, quindi si invia il proprio file python, i due script di test, i quattro file con i dati di test e lo script di build modificato per git. 7 nuovi e un file modificato in git, un altro file inviato al cliente.

L'idea del repository git è che posso iniziare con la tua azienda, prendere il mio computer vuoto, clonare il tuo repository git e avere tutto che ho bisogno di sviluppare.

Il tuo "rilascio" non è un archivio ZIP delle tue fonti, ma dovrebbe essere

• uno stato specifico del tuo progetto e
• qualsiasi numero di artefatti di build che possono essere installati / distribuiti.

Il tuo codice sorgente in corrispondenza di un commit corrisponde a un rilascio, ma non è la stessa cosa del rilascio. Invece, avrai un processo di sviluppo che crea artefatti (ad es. Pacchetti, dist, ruote, binari) dalla sorgente. È compito del processo di costruzione includere solo i file corretti.

I rami Git sono utili per rappresentare diversi thread di sviluppo che possono ramificarsi e unirsi di nuovo. Non è possibile (senza sforzi eccessivi) avere alcuni file o modifiche che vivono solo in rami specifici. Invece, il codice dovrebbe essere sempre in uno stato costruibile, su qualunque ramo viva.

La pagina "release" di GitHubs incorporata è principalmente una bella vista dei tuoi tag Git. Non devi usare questo. GH non impone il tuo flusso di lavoro. Tuttavia, è un modo poco impegnativo per ottenere un sito "download" per progetti open source. Usando le versioni di GH, puoi

• crea o usa un tag Git (ad esempio v1.2.3 )
• descrive la versione (spesso un log delle modifiche)
• aggiungi qualsiasi tipo di download

GH aggiunge l'archivio sorgente come predefinito scaricabile, ma puoi aggiungerne uno. Per un progetto Python, questa potrebbe essere una ruota o un sdist. Nota che GH offre un'API che ti consente di automatizzare il caricamento come parte del tuo script di compilazione. Alcuni provider di terze parti come Travis CI hanno integrazioni integrate.

Mi piacerebbe approfondire un po 'quello che @ maciej-stachowski ha detto:

That's not entirely correct, as far as I can tell. In GitHub, a release is a tag pointing to a specific commit - and while GitHub provides an option to download the source code corresponding to this tag as a .zip file from the release page

Anche questo non è del tutto corretto. GitHub utilizza git archive per creare file di archivio (.zip, .tar.gz) dal repository e ti offre il download. Il risultato dell'operazione git archive è ciò che ottieni quando fai clic sul pulsante Download ZIP sul master corrente o su un tag specifico.

Ora la cosa bella di git archive è che puoi effettivamente controllare cosa va nell'archivio, tramite il file .gitattributes . Anche se questo metodo non ti consente di eseguire alcun codice (quindi non puoi aggiungere file non nel tuo repository - né generando artefatti né scaricandoli), ti permette di filtrare i file che non vuoi nei tuoi archivi di origine. Un tipico file .gitattributes assomiglia a

# exclude .gitignore and similar from the generated tarball
.git*           export-ignore
# exclude CI configurations (useless outside the repo)
.travis-ci.yml  export-ignore
.appveyor.yml   export-ignore

In generale trovo una buona pratica escludere cose come .gitignore dai sorgenti-tarball; aiuta moltissimo se i pacchetti a valle utilizzino git per il packaging; spesso vogliono vedere tutti gli artefatti di costruzione che si tenta di nascondere con .gitignore ; anche le varie configurazioni CI sono normalmente utili solo nel contesto del tuo provider git (ad esempio GitHub).