Gestione del repository git

Question

Gestione del repository git

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

1

Non so se sto complicando troppo le cose, ma qui è il nostro setup.

3 server di hosting del codice (QA, stage e produzione)
3 rami principali di git ( dev , stage e master ) per i rispettivi server
10-15 sviluppatori che lavorano su git a volte lavorano sullo stesso file contemporaneamente.
Gli sviluppatori possono solo unire e inviare a dev , i manutentori gestiscono le versioni del codice per lo stage e la produzione.
eventuali problemi vengono eseguiti nel proprio ramo estratto dal ramo master (a volte dal ramo connesso).
ogni ramo viene unito singolarmente ai rami principali.
hanno variato le date di rilascio in modo che il master non sia sempre aggiornato. A volte un problema da dev può richiedere mesi per andare al master / produzione.

Attualmente stiamo affrontando un bel po 'di problemi di conflitto di codice su dev , il che sta anche sprecando molto del nostro tempo. Anche la cronologia o il grafico del codice sta cominciando ad apparire come lo spider web.

In precedenza ciò che avevamo era un setup lineare in cui ognuno si impegnava a svilupparsi, quindi i manutentori sceglierebbero i commit da mettere in scena o prod. Questa configurazione era più semplice per gli sviluppatori ma un incubo per i manutentori.

Se qualcuno ha esperienza con questo tipo di configurazione, si prega di avvisare su come hai semplificato il tuo lavoro? So che la comunicazione è la chiave qui, ma senza una persona dedicata lo trovo davvero impegnativo in questo momento.

git teamwork workflows

posta Ruchan 05.09.2018 - 10:37

fonte

2 risposte

Leggi altre domande sui tag git teamwork workflows

Motivo di progettazione per le proprietà comuni: proprietà statiche o una classe di istanza singola separata? È consentito lanciare un'eccezione di runtime da un java.util.Predicate

score 2 · Answer 1

Non sono completamente chiaro su quale sia il tuo processo. Ma!

Se utilizzi correttamente le funzioni e i rami di aggiornamento rapido, dovresti ottenere solo conflitti di unione quando hai effettivamente un conflitto.

Sviluppatori ramo da sviluppare - > feature123 e costruisce una funzione, attivando la feature123 mentre vanno.

Quando hanno finito si fondono dallo sviluppo - > feature123 di nuovo per rilevare eventuali modifiche che si sono verificate durante lo sviluppo di altre funzionalità o hotfix durante il loro funzionamento.

Qui, se qualcuno ha cambiato lo stesso codice come te, otterrai un conflitto di fusione. Dovrai decidere in che modo la tua funzione dovrebbe funzionare con il codice modificato.

Quando lo sviluppatore risolve il conflitto, può unire feature123 - > sviluppare

Una volta che tutte le funzionalità di una versione sono terminate, puoi unire lo sviluppo del modulo - > Master

Maintainers branch da master - > hotfix123 e apportare modifiche in hotfix123. Una volta completati, uniscono hotfix123 in entrambi i master E sviluppano

Qui possono ottenere conflitti da altri hotfix che cambiano lo stesso codice (si spera raramente) e dalle nuove funzionalità aggiunte dagli sviluppatori.

Questa sarà l'unione più difficile in quanto il Maintainer e lo Sviluppatore si trovano in team diversi e dovranno collaborare all'unione.

score 0 · Answer 2

Gli sviluppatori dovrebbero unire regolarmente master in, l'ultima volta quando si esegue la funzione e solo unire nuovamente al master quando il loro lavoro è correttamente integrato. Ciò garantisce che master sia sempre utilizzabile da altri.

Questo è importante per garantire che funzionino contro l'ultimo codice rilasciato. È nel loro stesso interesse, quindi dovrebbero prenderlo in fretta. È molto più semplice eseguire correzioni di unione incrementale rispetto a Cascate Unite.