Utilizzare l'unione o il rebase per mantenere un ramo di distribuzione

Question

Ospito con AWS che significa che non posso utilizzare le variabili di ambiente per controllare le distribuzioni di produzione e gestione temporanea. Sono quindi costretto a utilizzare filiali separate per l'implementazione e mi chiedo se esiste un approccio di best practice per la loro manutenzione?

Se unisco le modifiche nel mio ramo di produzione, il commit che contiene le mie impostazioni di produzione andrà perso nella cronologia dei rami, rendendo più difficile modificare tali impostazioni.

Tuttavia, ho letto che non si dovrebbe usare rebase in questa situazione in quanto renderà più difficile il rollback delle modifiche.

Answer 1

Si potrebbe versione due file di impostazioni (una per dev e uno per prod)

Poi si potrebbe lasciare a uno script "elasticbeanstalk/hook" per scrivere il file settting reale per lei dopo un "git aws.push".

È possibile visualizzare un esempio di un problema simile in "How to get Elastic Beanstalk nginx-backed proxy server to auto-redirect from HTTP to HTTPS?", relativo a un'app Nodo (che potrebbe non essere il caso esatto), in cui un file .ebextensions/config scriverà un /opt/elasticbeanstalk/hooks/configdeploy/enact/myscript.sh.

L'ultimo script è un hook che può essere eseguito sulla distribuzione e può aggiornare il file di configurazione attuale del proprio ambiente.

Answer 2

Ho anche affrontato molte sfide per implementare git nel mio ultimo progetto. Dopo aver cercato su Google ho trovato questo blog ed è davvero un bel modo per mantenere il modello di git branch.

A successful Git branching model Il repo centrale tiene due rami principali con durata infinita:

• maestri
• sviluppare

Il branch master in origine dovrebbe essere familiare ad ogni utente Git. Parallelamente al ramo principale, esiste un altro ramo chiamato sviluppo.

Consideriamo origine/master il ramo principale in cui il codice sorgente di HEAD riflette sempre uno stato pronto per la produzione.

Consideriamo origine/sviluppo il ramo principale in cui il codice sorgente di HEAD riflette sempre uno stato con le ultime modifiche allo sviluppo consegnate per la prossima versione. Alcuni lo chiamerebbero il "ramo dell'integrazione". Da qui vengono create tutte le build notturne automatiche.

rami di supporto

I diversi tipi di rami che ci all'utente sono:

• Feature rami
• rami di rilascio
• rami Hotfix

Rami di funzione: I rami di funzionalità (o talvolta denominati rami di argomenti) vengono utilizzati per sviluppare nuove funzionalità per la prossima o futura release.

maggio diramano da: sviluppare

necessario unire nuovamente dentro: sviluppare

Branch convenzione di denominazione: nulla, se non maestro, sviluppare, release- , o hotfix-

Rilasciare i rami: I rami di rilascio supportano la preparazione di una nuova versione di produzione. Consentono la punteggiatura dell'ultimo minuto di i e l'attraversamento di t.

maggio diramano da: sviluppare

necessario unire nuovamente dentro: sviluppare e padroneggiare

Branch convenzione di denominazione: Release- *

rami Hotfix: rami Hotfix sono molto come i rami di rilascio in quanto sono anche pensati per preparare una nuova versione di produzione, anche se non pianificata. Esse derivano dalla necessità di agire immediatamente su uno stato indesiderato di una versione di produzione dal vivo.

Può diramano da: maestro

necessario unire nuovamente dentro: sviluppare e maestro

Branch convenzione di denominazione: hotfix- *

Potete trovare maggiori dettagli su questo modello di ramificazione Git dal blog. I comandi utilizzati per il modello di ramificazione sono elencati anche nel blog. Check the blog per maggiori dettagli. Ho implementato con successo il modello di ramificazione nel mio progetto con alcune modifiche dal modello menzionato nel blog. Git è uno strumento potente e flessibile, e questo è solo un modo di usare Git.

Answer 3

Su master, versione entrambi i file di impostazioni (settings_master e settings_prod) e un collegamento simbolico settings -> settings_master. Ora, diramazione prod spenta master (o unire master in prod se esiste già) e, in prod, modificare solo il collegamento simbolico settings in modo che punti a settings_prod.

Confermare questa modifica su prod.

Ora fare tutto lo sviluppo su master, e finché non si modifica il collegamento stesso (cambiando uno dei file di impostazioni va bene), si sarà in grado di unire in masterprod tutte le volte che vuoi senza influenzare l'obiettivo di settings. La tua applicazione dovrebbe recuperare la sua configurazione da settings.

Questo si tradurrà in una storia commettere che assomiglia a questo:

... -o---o---o---o master 
     \  \ \ 
... --o-------o---o prod 

Il diff master-prod dopo ogni fusione di master in prod saranno sempre esattamente:

--- a/settings 
+++ b/settings 
@@ -1 +1 @@ 
-settings_master 
\ No newline at end of file 
+settings_prod 
\ No newline at end of file 

Answer 4

ci sono alcuni link qui sotto che condividono alcune opinioni sulle metodologie e il ragionamento dietro al motivo per cui dovresti scegliere rebase o fusione.

• L'unione è ideale per l'inserimento di codice in una filiale condivisa tra una squadra. Poiché Rebase riscrive la cronologia dei commit, il contesto dei commit correlati (come la funzione branching) viene perso poiché i commit diventano lineari in base ai timestamp.
• Rebase può essere ideale per estrarre il codice nel ramo di lavoro prima di eseguire il commit su un ramo condiviso. I risultati lineari e il cambiamento storico possono portare a una fusione più riuscita dei commit.

See:

• http://blogs.atlassian.com/2013/10/git-team-workflows-merge-or-rebase/
• http://www.derekgourlay.com/archives/428