Auto-fusione dal master a tutti i rami - buona o cattiva idea?

Question

Auto-fusione dal master a tutti i rami - buona o cattiva idea?

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

2

Una domanda è emersa sul team: sarebbe una buona o una cattiva idea avere uno script che si fonda automaticamente dal master a tutte le filiali di questa release su base giornaliera?

Non ne sono del tutto convinto - sembra che la fusione possa generare conflitti (e in tal caso la sceneggiatura andrebbe indietro), ma anche se così non fosse, posso immaginare casi in cui sto lavorando su qualche enorme refactoring sul mio ramo, per qualche ragione voglio commetterlo e spingerlo e poi può succedere che non possa perché il master è stato cambiato nel mezzo! In quei (rari) casi mi verrebbe lasciata senza opzione che a git push --force o semplicemente non spingere le mie modifiche.

Cosa ne pensi di questo? I team usano questi tipi di script altrove?

Grazie

git version-control

posta devoured elysium 05.09.2016 - 12:05

fonte

4 risposte

Leggi altre domande sui tag git version-control

Prima i dati o prima il codice? Come funziona questo compito in C ++?

score 3 · Answer 1

Il mio istinto mi dice che non lo farei. I problemi probabilmente ne superano i vantaggi:

conflitti
non voglio unire ancora
rollback cancellati accidentalmente dallo script
che desidera unire due rami in un ordine particolare
...

Nei casi banali di fusioni semplici senza conflitti, eseguirlo manualmente richiede comunque un paio di secondi. E negli altri casi, probabilmente uno script non può aiutarti.

score 2 · Answer 2

would it be a good or a bad idea to have a script auto merge from master to all this release's branches on a daily basis?

Su base giornaliera ? No. "master" cambia ogni giorno?

Avere periodicamente un po 'di cambiamenti a vapore su tutto il tuo codice precariamente bilanciato che si limita a compilare e non è quasi pronto per il rilascio è solo un problema.

Dopo una tale fusione, è probabile che la tua squadra spenda molto del suo tempo per svelare il danno arrecato al loro codice o anche solo rieseguire i test di regressione e ordinare "cosa è cambiato", nessuno di cui c'è qualcosa a che fare con la funzionalità / correzione di bug / ecc. su cui supposto sta lavorando.

score 2 · Answer 3

L'automazione non è in conflitto con l'idea principale dei rami di rilascio? Un ramo di rilascio (come ho capito) è quello di avere la possibilità di guardare indietro alla cronologia di una versione già rilasciata, o aggiungere una patch (ad esempio cliente 1 get v1.0, oops c'è un errore, noi consegniamo v1.0.1 ). La fusione del master in un ramo di rilascio aggiungerebbe anche nuove funzionalità, il che rende il ramo imprevedibile e instabile.

L'ho visto al contrario - una correzione è stata eseguita nel ramo di rilascio interessato e poi reimmessa nel master. Questo è sempre stato un compito manuale.

D'altra parte, la fusione di release + master senza push (!) può essere utile in un ambiente CI per verificare la potenziale compatibilità.

score 1 · Answer 4

L'integrazione quotidiana dal master a tutti i rami delle funzionalità offre molti vantaggi a molti team. Tuttavia, non dovrebbe accadere senza sorveglianza. Sembra che quello che vuoi veramente sia un promemoria quotidiano per te e i membri del tuo team per provare un'unione dal master ai rami delle funzionalità correnti. Quindi, se vuoi automatizzarlo, puoi invece eseguire una sorta di dry-run, come descritto here , senza influire sul ramo di funzione o sulla copia locale corrente. Se la corsa a secco mostra conflitti di fusione, invia allo sviluppatore un messaggio sui conflitti che deve aspettarsi, se non lo fa, non infastidirlo né la squadra.