Come utilizzare github, filiali e versioni automatiche per la gestione delle versioni? [chiuso]

Ormai capisco la maggior parte dei concetti di base di Git / Github, tuttavia ho ancora problemi a comprendere il quadro generale.

Queste sono alcune cose che sono riuscito a far funzionare finora:

• Push si impegna
• Lavora con i rami
• Integra Github con Travis CI, un sistema di integrazione continua
• Tramite Travis CI, si basa automaticamente su ogni commit da padroneggiare e inserisce la versione come ZIP su Github nelle versioni.

Tuttavia, finora ho lavorato solo su versioni alfa / beta di progetti, quindi non ho mai visto versioni con versioni in pratica.

Quindi voglio saperne di più sul controllo delle versioni, sul mantenimento di versioni separate, sull'aggiornamento rapido delle versioni, ecc.

Come assicurerei che accadano le seguenti cose:

• Ho versioni diverse del mio progetto, ad esempio versione 1.1.0 e 2.0.0
• Avere la possibilità di inviare aggiornamenti rapidi sulle versioni, in qualche modo superare la versione 1.1.1 o 2.0.1, ecc.
• Crea un sistema di integrazione continua costruisci automaticamente quella versione su commit e, se ha esito positivo, pubblica una versione per quella versione specifica.

Dubito tra le seguenti opzioni:

• Devo usare i tag per ogni versione? In tal caso, come può un sistema di integrazione continua generare automaticamente le versioni?
• Devo creare filiali per ogni versione? Se è così, ciò non creerebbe un'intera tonnellata di rami (come un ramo 1.1 e 2.0, gli hotfix vanno ovviamente su quel ramo)
• Come specificare il numero di versione? Va bene avere un file di configurazione che specifica il numero di versione o ci sono modi più intelligenti per aggirarlo? In questo caso sarebbe un progetto Java, se questo è importante.

Dovresti guardare git-flow . È un modello di ramificazione eccellente (e popolare).

Riepilogo Git Flow

branching

I tronchi principali che rimangono in giro per sempre sono develope master. mastercontiene l'ultima versione e developcontiene l'ultima copia di sviluppo "stabile".

I collaboratori creano featurefiliali (con prefisso feature/per convenzione) da develop :

$ git checkout -b feature/my-feature develop

e hotfixfiliali (precedute da hotfix/per convenzione) al di fuori di master:

# hotfix the latest version of master
$ git checkout -b hotfix/hotfix-version-number master

# or hotfix from a specific version
$ git checkout -b hotfix/hotfix-version-number <starting-tag-name>

Questi rami sono "usa e getta", nel senso che hanno una breve durata prima di essere ricongiunti ai tronchi principali. Hanno lo scopo di incapsulare piccoli pezzi di funzionalità.

Filiali di finitura

Quando un contributore ha terminato un featureramo, lo ricollegano in develop:

$ git checkout develop
$ git merge --no-ff feature/my-feature
$ git branch -d feature/my-feature

Quando hanno finito con un hotfixramo, lo uniscono nuovamente in entrambi mastere developquindi l'aggiornamento rapido prosegue:

$ git checkout master
$ git merge --no-ff hotfix/hotfix-version-number
$ git checkout develop
$ git merge --no-ff hotfix/hotfix-version-number
$ git branch -d hotfix/hotfix-version-number

Questo è l'aspetto di integrazione continua.

Uscite

Quando sei pronto per iniziare a creare un rilascio, crei un releaseramo dal tuo ramo "stabile" develop(lo stesso della creazione di featurerami). Quindi si esegue il bump del numero di versione in un tag (descritto di seguito).

L'uso di releaserami separati ti consente di continuare a sviluppare nuove funzionalità developmentre correggi i bug e aggiungi tocchi finali al releaseramo.

Quando sei pronto per terminare il rilascio, unisci il releaseramo in entrambi mastere develop(proprio come a hotfix) in modo che tutte le modifiche proseguano.

Tagging

Quando si crea un releaseramo o un hotfixramo, il numero di versione viene sommato in modo appropriato in un tag. Con Vanilla Git, è così:

$ git tag -a <tag-name> -m <tag-description>

Dovrai quindi anche inviare i tag (separatamente) al tuo repository remoto:

$ git push --tags

Di solito è meglio usare il versioning semantico in cui le tue versioni prendono la forma major.minor.hotfix. I dossi principali sono incompatibili all'indietro, mentre i dossi minori e gli hotfix non sono incompatibili all'indietro (a meno che non siate in beta, 0.x.x).

Fusione

Come hai visto sopra, git-flow ti incoraggia a unire i rami con il seguente comando:

$ git merge --no-ff <branch-name>

L' --no-ffopzione ti consente di mantenere tutta la cronologia dei tuoi rami senza lasciare un mucchio di rami nell'attuale commit del repository (quindi non preoccuparti, non avrai un ramo per ogni versione).

Sei anche incoraggiato a tirare avanti

$ git pull --rebase

Quindi non aggiungi molti inutili commit di unione.

Puoi configurare git per fare entrambe queste cose di default nel tuo .gitconfig. Ti lascio comunque cercare quello;)

Versioni di navigazione

Quando qualcuno cerca una versione specifica del tuo codebase, può controllare il tag per nome:

# checkout in detached HEAD to browse
$ git checkout <tag-name>

# OR checkout and create a new local branch (as you might for a hotfix)
$ git checkout -b <new-branch-name> <tag-name>

Oppure, se qualcuno sta navigando su github, c'è anche una scheda "tag" nel menu a discesa "rami".

Utilizzo dell'estensione git-flow (consigliata)

Il mio modo preferito di usare questo modello è con l' estensione git flow per git.

( Modifica: Louis ha raccomandato il fork AVH che funziona meglio con git describee potrebbe essere più attivo ora. Grazie Louis.)

L'estensione automatizza tutte le parti disordinate (come l'utilizzo merge --no-ffe l'eliminazione di rami dopo l'unione) in modo da poter andare avanti con la tua vita.

Ad esempio, con l'estensione, è possibile creare un ramo di funzionalità in questo modo:

$ git flow feature start my-feature-name

e finisci così

$ git flow feature finish my-feature-name

I comandi per gli aggiornamenti rapidi e le versioni sono simili, sebbene utilizzino il numero di versione al posto del nome di un ramo, in questo modo:

# Create hotfix number 14 for this minor version.
$ git flow hotfix start 2.4.14

# Create the next release
$ git flow release start 2.5.0

Git flow crea quindi il tag di versione per te e ti ricorda gentilmente di salvare la versione in qualsiasi file di configurazione o manifest (cosa che potresti fare con un task manager come grunt).

Spero che sia d'aiuto :) Non sono sicuro di come integreresti tutto con la tua configurazione di Travis CI, ma immagino che Githooks ti porterà lì.

Devo usare un tag per ogni versione?

No, non è necessario utilizzare i tag. Se vuoi taggare ogni versione, va bene, o se vuoi taggare ogni volta che il tuo sistema CI viene compilato, puoi farlo anche tu. I tag essenzialmente danno semplicemente un nome user friendly al commit, in modo che tu possa facilmente recuperarlo e visualizzarlo in un secondo momento.

Devo creare filiali per ogni versione?

Sicuro! La ramificazione è economica / gratuita in Git, quindi ne approfitto ogni volta che ne ho l'occasione. Puoi anche unire ed eliminare i rami abbastanza rapidamente. Se ritieni di avere molti rami puoi sempre abbatterli in seguito con una fusione selettiva. Ci sono anche una serie di schemi di ramificazione Git disponibili se si desidera utilizzare uno schema provato e vero.

Come specificare il numero di versione?

I tag sono in genere il modo in cui specifichi il numero di versione, in quanto riguarda git. Se stai parlando di come eseguire la versione di un progetto o il modo migliore per farlo, dovrai scavare, dato che si tratta di una domanda abbastanza basata sull'opinione. Alcuni progetti rimangono in beta per sempre, altri incrementano le versioni di numeri interi come se stessero andando fuori moda (ti guardano Chrome)

Devo usare i tag per ogni versione?

Se per "versione" intendi un insieme di file che compongono una versione o un candidato alla versione, ti consiglio vivamente di taggare ogni versione. Se devi fare riferimento alla versione 1.2.7, vuoi cercare l'hash di un commit o semplicemente utilizzare il numero di versione?

Inoltre, se si utilizza git describeper registrare informazioni sulla build da qualche parte (come faccio io), l'utilizzo dei tag consente di fornire risultati molto più piacevoli.

In tal caso, come può un sistema di integrazione continua generare automaticamente le versioni?

Un sistema di integrazione continua potrebbe creare rilasci indipendentemente da come si utilizzano i tag. Potresti dirlo per creare una versione sulla base dell'hash di un commit. I tag ti semplificano la vita.

Devo creare filiali per ogni versione? Se è così, ciò non creerebbe un'intera tonnellata di rami (come un ramo 1.1 e 2.0, gli hotfix vanno ovviamente su quel ramo)

Non vedo la ramificazione come una cosa "per versione". Ho un paio di progetti in cui le mie versioni sono tutte impegnate nella masterfiliale. Non ho bisogno di nulla di più complicato di questo per ora perché nessuno dei due progetti è in fase stabile e non è necessario supportare versioni precedenti a lungo termine. Ma supponiamo di rilasciare la versione 1.0, 1.1, 1.2, quindi la versione 2.0 e devo ancora supportare la serie 1.0 con correzioni di sicurezza, ecc. Quindi avrei sicuramente un ramo su cui mettere le versioni di manutenzione per la serie 1.x .

Come specificare il numero di versione? Va bene avere un file di configurazione che specifica il numero di versione o ci sono modi più intelligenti per aggirarlo? In questo caso sarebbe un progetto Java, se questo è importante.

Avere un'unica fonte per il tuo numero di versione, come un file di configurazione, è il modo migliore in quanto previene errori di dito grasso che potrebbero altrimenti verificarsi se si devono aggiornare i numeri in più punti. Sto parlando da ... hmm ... esperienza imbarazzante. Rilasci 1.3 solo per scoprire che il software riporta ancora che è la versione 1.2. Oops!

In un'altra risposta, mxdubois ti ha raccomandato gitflow. Se decidi di usare gitflow, ti consiglio di usare l' edizione AVH . La versione originale non viene più mantenuta attivamente. Una notevole differenza è che l'edizione AVH esegue le fusioni di rilascio che consentono git describedi lavorare in modo intelligente. La versione originale esegue l'unione in modo tale da inciamparegit describe .

Scansionando la mia lista vedo la versione come focus, quindi ...

Un modo per mantenere le versioni è con le filiali e l'unione (o la riformulazione).

Quindi hai:

master

quindi crei un ramo

v1

quindi aggiungi altre modifiche a

master(diff1)

quindi crei un ramo

v3

quindi aggiungi altre modifiche a

master(diff2)

Adesso:

Per aggiornare la versione 2 ora lo fai

git checkout v2
git merge master  # for the changes you want to bring into version 2
# rebasing is also an option
# resolve any merge conflicts
# Done.

Per aggiornare la versione 3

git checkout v3
git merge master

Quanto sopra è per gli aggiornamenti all'ingrosso.

Probabilmente è più probabile però che tu voglia scegliere cambiamenti specifici per quello che c'è

git cherry-pick

Maggiori informazioni sulla raccolta delle ciliegie su http://git-scm.com/docs/git-cherry-pick