Stiamo cercando di adottare il modello di ramificazione Git di successo implementato da git-flow. Ora stiamo lavorando su almeno due rami di rilascio, uno per l'ultima versione stabile e uno per il prossimo ("anteprima"). Quello che non capisco è il motivo per cui tutte le versioni sembrano "linearizzate" al master e contrassegnate lì. Perché non contrassegnare le versioni nei loro rami di rilascio? Perché il maestro ? O perché un ramo di sviluppo e non utilizzare master per questo?
Risposte:
Nel modello git-flow, la tua "ultima versione rilasciata" in realtà mappa a master, mentre la tua "versione di anteprima" mappa a un releaseramo git-flow . Viene biforcato develope infine unito a masterquando avviene il rilascio effettivo. Quindi questa diventerà la tua "ultima versione" e di solito correggerai solo i bug per quella versione, usando i hotfixrami git-flow . In questo modo, il tuo masterrappresenta sempre lo stato più stabile della tua ultima versione rilasciata.
Se vuoi correggere i bug per le versioni precedenti o fare qualsiasi altro sviluppo lì, eseguirai il fork di un supportramo dal commit appropriato in master(avrai tutte le versioni mai create lì). supporti rami sono ancora sperimentali ( secondo i documenti ) e non sono ben documentati. Ma come puoi vedere dalla guida della riga di comando:
usage: git flow support [list] [-v]
git flow support start [-F] <version> <base>
questi rami sono appena stati avviati e non devono essere fusi in masternor develop. Questo di solito va bene, poiché le correzioni alle versioni "antiche" o alle funzionalità richieste dai clienti per essere implementate nelle versioni "antiche" non possono o non devono tornare indietro master. Se pensi ancora di voler portare una correzione alla tua linea di sviluppo principale (rappresentata da mastere develop), avvia semplicemente un hotfix, seleziona le tue modifiche e termina il file hotfix.
git flow supportnon è contrassegnato come sperimentale.
Sembra principalmente un modello mentale con un po 'troppa enfasi sui rami. Sono d'accordo, potresti semplicemente taggare i commit che rilasci invece di unirli di nuovo nel master.
L'immagine è carina, però. Unire tutto di nuovo nel master fornisce una chiara indicazione delle versioni in ordine temporale invece di avere tag di versione sparsi in tutto il grafico.
Penso che questo modello non funzioni per la correzione dei bug nelle versioni precedenti, però. Incasina l'ordine pulito.
Per rispondere alla tua domanda: penso che questo sia un insieme di regole che in alcuni casi costituisce un semplice modello mentale. Non tutte le regole hanno senso da un punto di vista puramente tecnico, ma questo non le rende cattive. I modelli mentali vanno bene per loro umani.
supporti rami sono progettati per correggere i bug nelle versioni precedenti, sebbene siano ancora etichettati come "sperimentali".
Personalmente penso che il citato git-flow sia troppo complicato.
Se stai usando GitHub prova il GitHub flow(come descritto da Scott Chacon).
È particolarmente utile per la collaborazione su più funzionalità, la revisione del codice e puoi combinarlo con la tua soluzione di integrazione continua utilizzando il Commit Status API.
AGGIORNAMENTO : C'è un nuovo sito web ufficiale di The GitHub Flow ™
AGGIORNAMENTO 2 : c'è una nuova guida GitHub ufficiale (e semplificata) per The GitHub Flow ™: https://guides.github.com/introduction/flow/
master, un'anomalia della cronologia dell'opera.
supportservono i rami. Ma hai ragione, è davvero un'anomalia in cui tali rilasci non vengono riuniti master, cosa che, a quanto mi risulta , dovrebbe contenere tutte le versioni di produzione.
Nel mio caso, ho due versioni dello stesso software che le basi sono le stesse ma ogni versione ha alcune caratteristiche diverse.
Quindi ne creo due worktreeche significa, creo due rami di lunga durata rilevanti accanto al master.
$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master
Dopo io ho:
$git branch
master # base stuff here
version-silver # some normal features
version-gold # some better features
C'è un repository, ma ho 3 cartelle separate una accanto all'altra per ogni ramo sopra. E apporta le modifiche comuni in master. quindi uniscilo con entrambe le altre versioni.
cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here i get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here i get the basic.cpp latest changes for gold project
Anche le modifiche specifiche di ciascuna versione andranno nella cartella corrispondente e i lavori su ciascun progetto saranno isolati e l'IDE non sarebbe confuso.
Spero possa aiutare.
Totalmente d'accordo con @Mot.
È bello sentire le stesse domande.
Il nostro team è stato anche cacciato per un modello di ramificazione più universale rispetto a quello di successo . Ad esempio, come menzionato sopra @Mot, l'idea principale è quella di evitare di introdurre repository aggiuntivi per supportare i rami release- * in repository * .git separati, come ad esempio è fatto da kernel.org per le versioni stabili. Ma kernel.org lo fa per ridurre al minimo le dimensioni scaricate, immagino.
Per me sembra che sia più pulito avere il master come linea principale per lo sviluppo .
Inoltre ci sono alcuni conflitti in release- * unire il modello da master e taggarlo successivamente con l'idea a
usa uno script hook Git per creare e distribuire automaticamente il nostro software ai nostri server di produzione ogni volta che c'era un commit sul master
perché la finitura (unione e codifica) non è una transazione atomica:
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2
e se git hook inizia a costruire con il supporto per il controllo automatico delle versioni:
$git describe --tags --long >.ver
allora è possibile costruire una versione sbagliata per:
$ git merge --no-ff release-1.2
So che il controllo delle versioni in Successfull introduce un processo di bump-version ma non è automatico.
Quindi, per riassumere, le differenze chiave che introduciamo al modello di ramo per i rilasci * l'unione e il tagging sono: - taggare il rilascio sulla creazione del suo ramo - mantenere il ramo del rilascio per abilitarne la manutenzione in futuro
Il ramo master dovrebbe SEMPRE rappresentare la tua base di codice di produzione, quindi unisci sempre il codice al master subito dopo un rilascio di produzione.
Il tagging viene utilizzato per "memorizzare" il codice esatto che è stato inserito in una versione di produzione in modo da poter tornare indietro in un secondo momento e analizzare il codice se qualcosa è andato storto.
Con questo teoricamente non dovrebbe importare se tagghi il tuo codice sul ramo di rilascio o sul ramo master dopo che sei tornato al master. Personalmente preferisco taggare il codice sul ramo di rilascio poiché questo è esattamente il codice inserito nella build / release (supponendo che qualcosa possa andare storto con l'unione).
Il problema con il concetto di ramo di sviluppo è che è a thread singolo. Brendan in questo thread ha menzionato una strategia che potrebbe essere utilizzata coinvolgendo un concetto di ramo di sviluppo.