Comprensione della strategia di ramificazione / flusso di lavoro correttamente [duplicato]

Question

Comprensione della strategia di ramificazione / flusso di lavoro correttamente [duplicato]

#1 da (4 voti)
#2 da (0 voti)

4

Sto usando svn senza rami (solo trunk) per molto tempo sul mio posto di lavoro. Ho scoperto la maggior parte o tutte le questioni relative a progetti che non hanno alcuna strategia di ramificazione. Improbabile che questo non cambierà sul mio posto di lavoro ma per i miei progetti privati.

Per i miei progetti privati che includono la maggior parte dei colleghi e che lavorano insieme allo stesso tempo su diverse funzionalità mi piace avere una solida strategia di ramificazione con supporto di rilasci a lungo termine basati su git.

Scopro che l'Atlassian Toolchain (JIRA, Stash e Bamboo) mi ha aiutato di più e mi consiglia anche una strategia di ramificazione che mi piace verificare per le esigenze della squadra.

La strategia di diramazione è stata presa direttamente dalla raccomandazione di Atlassian Stash con una piccola modifica alla struttura del ramo di aggiornamento rapido. Tutti gli hotfix dovrebbero anche essere uniti nella linea principale.

Lastrategiadiramificazioneinparole

mainline(notoanchecomemastercongitotrunkconsvn)contienelaversionedisviluppo"state of the art". Tutto qui è stato controllato con successo con vari test automatici (tramite Bamboo) e sembra che tutto funzioni. Non è dimostrato come funzionante a causa di possibili test mancanti. È pronto per l'uso ma non consigliato per la produzione.
La funzione copre tutte le nuove funzionalità che non sono completamente finite. Una volta che una funzionalità è finita, verrà unita in linea principale . Campione di esempio: feature/ISSUE-2-A-nice-Feature
bugfix corregge bug non critici che possono attendere la prossima versione normale. Campione di esempio: bugfix/ISSUE-1-Some-typos
production possiede l'ultima versione.
hotfix corregge bug critici che devono essere rilasciati urgenti per mainline , production e tutti i release a lungo termine interessati . Campione di esempio: hotfix/ISSUE-3-Check-your-math
rilascio è per la manutenzione a lungo termine. Rami di esempio: release/1.0 , release/1.1 release/1.0-rc1

Non sono un esperto quindi ti preghiamo di fornirmi un feedback. Quali problemi potrebbero apparire? Quali parti mancano o rallentano la produttività?

git branching svn

posta burnersk 06.06.2014 - 14:00

fonte

2 risposte

0

link delinea un analogo modello di ramificazione che lo scrittore afferma di aver usato con successo su un certo numero di progetti.

Punti chiave:

due rami longevi, master e development , con il primo per il codice pronto per la produzione e il secondo il ramo integration .
rami per feature , release e hotfix . Questi esistono solo per la durata del lavoro in questione, a differenza dei rami di lunga durata sopra menzionati.
feature rami escono da development e sono unificati al suo interno una volta completati. Questi di solito esistono solo nei repository degli sviluppatori.
release branches provengono da development e sono unificati in development e master . L'obiettivo è quello di evitare grossi cambiamenti di rottura in master che causano problemi per una versione imminente. Di conseguenza, questi rami vengono in genere creati appena prima del rilascio di un rilascio.
hotfix branches provengono da master e sono unificati in master e development . Questi sono destinati a risolvere i problemi di produzione critici.

risposta data 06.06.2014 - 14:38

fonte

Leggi altre domande sui tag git branching svn

È meglio memorizzare i log di utilizzo in modo saggio o centralizzato? Quando utilizzare un metodo statico invece di un costruttore?

score 4 · Accepted Answer

La risposta più breve: nessuna strategia di ramificazione singola sarà ottimale per ogni progetto, in quanto tale la strategia che hai sopra sarà perfetta per alcuni progetti che hai e inutili per gli altri.

I vari fattori che devi tenere a mente sono (tra gli altri, se ne suggeriscono altri li modificherò felicemente in questa risposta):

Il progetto ha uscite univoche o è continuamente rilasciato?
Il software di progetto è distribuito ai clienti o reso disponibile come servizio sul proprio hardware?
Se il software ha versioni univoche, le versioni più recenti hanno sempre versioni obsolete obsolete o anche le versioni precedenti devono essere mantenute?
Quanto sono esperti i tuoi contributori? Sono tutti sviluppatori di grande esperienza o sarà necessario fare concessioni a personale non tecnico come i progettisti?
Quanto tempo ho intenzione di investire per mantenere la cronologia del progetto pulita e in ordine?

La strategia che hai descritto sopra è ottimale per il caso di:

Il progetto ha versioni uniche.
Il codice del progetto viene distribuito ai clienti.
Le versioni precedenti dovranno essere mantenute.
! Non descrive il modo in cui viene gestita la fusione, cioè rebase-first, no-ff, esistenza di merge commit, ecc. E come tale è ambigua sul punto dell'esperienza contributore.
! Dal momento che non affronta la fusione, è anche ambiguo sull'investimento sul punto di tempo.

Detto questo, una domanda molto più utile da porsi è in questa forma: "Il mio progetto è strutturato come [questo], qual è la strategia di ramificazione ottimale per questo, quali sono gli svantaggi che ha?"