Dovresti dare un'occhiata a git-flow . È un eccellente (e popolare) modello di ramificazione.
Riepilogo del flusso Git
Branching
I tronchi principali che restano per sempre sono develop e master . master contiene la tua ultima versione e develop contiene la tua ultima copia di sviluppo "stabile".
Collaboratori creano feature rami (prefissati con feature/ per convenzione) su develop :
$ git checkout -b feature/my-feature develop
e hotfix rami (prefissati con hotfix/ per convenzione) off 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", il che significa che hanno una breve durata prima di essere uniti ai tronchi principali. Sono pensati per incapsulare piccoli pezzi di funzionalità.
Rami di finitura
Quando un contributore ha finito con un ramo feature , lo uniscono nuovamente a develop :
$ git checkout develop
$ git merge --no-ff feature/my-feature
$ git branch -d feature/my-feature
Quando hanno finito con un ramo hotfix , lo uniscono nuovamente in master e develop , quindi 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 dell'integrazione continua.
Comunicati
Quando sei pronto per iniziare il confezionamento di un rilascio, crei un ramo release dal tuo ramo "%" develop (uguale a creare feature rami). Quindi si esegue il bump del numero di versione in un tag (descritto di seguito).
L'utilizzo di filiali release separate ti consente di continuare a sviluppare nuove funzionalità su develop mentre correggi bug e aggiungi ritocchi finali al ramo release .
Quando sei pronto per completare il rilascio, unisci il ramo release in master e develop (proprio come hotfix ) in modo che tutte le modifiche vengano portate avanti.
Tagging
Quando crei un ramo release o un ramo hotfix , esegui il bump del numero di versione in modo appropriato in un tag. Con van git, assomiglia a questo:
$ git tag -a <tag-name> -m <tag-description>
Dovrai poi inserire i tag (separatamente) nel tuo repository remoto:
$ git push --tags
Di solito è meglio usare versioning semantico in cui le tue versioni assumono il formato major.minor.hotfix . I dossi principali sono incompatibili all'indietro, mentre quelli secondari e quelli con hotfix non sono incompatibili all'indietro (a meno che tu non sia in beta, 0.x.x ).
La fusione
Come hai visto sopra, git-flow ti incoraggia a unire rami con il seguente comando:
$ git merge --no-ff <branch-name>
L'opzione --no-ff ti consente di conservare tutta la cronologia del tuo ramo senza lasciare un mucchio di rami nel commit corrente del repository (quindi non preoccuparti, non avrai un ramo per ogni versione).
Sei anche incoraggiato a tirare con
$ git pull --rebase
Quindi non aggiungi molti commit inutili di fusione.
Puoi configurare git per fare entrambe queste cose per impostazione predefinita in .gitconfig . Ti lascerò comunque vedere quello;)
Versioni di navigazione
Quando qualcuno sta cercando una versione specifica della tua base di codice, può eseguire il checkout del 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 "branches".
Uso dell'estensione git-flow (consigliato)
Il mio modo preferito per utilizzare questo modello è con l'estensione git flow per git.
( Modifica: Louis ha raccomandato il fork AVH che funziona meglio con git describe e potrebbe essere più attivo ora. Grazie Luigi.)
L'estensione automatizza tutte le parti disordinate (come l'utilizzo di merge --no-ff e l'eliminazione di rami dopo l'unione) in modo che tu possa andare avanti con la tua vita.
Ad esempio, con l'estensione, puoi 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 hotfix e release sono simili, anche se usano 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 quindi crea il tag della versione per te e ti ricorda gentilmente di eseguire il bump della versione in qualsiasi file di configurazione o manifest (cosa che potresti fare con un task manager come grunt).
Spero di esserti stato utile :) Non sono sicuro di come integreresti tutto con il tuo setup di Travis CI, ma suppongo che i githook ti porteranno lì.