Come inizio a utilizzare Git per basi di codice diverse da server diversi?

Spingi il materiale di produzione nel ramo master di un nuovo repository. Creare un ramo develop da quello e quindi unire il server di staging in esso. Potresti finire con conflitti che devono essere risolti. Una volta risolti, crea un altro feature_branch da develop e unisci il server di sviluppo al suo interno. Risolvi eventuali conflitti che si verificano.

Questo ti lascia con 3 rami, che rappresentano gli ambienti di produzione, di staging e di sviluppo. Produzione - > master , staging - > develop , sviluppo - > %codice%. Tutto lo sviluppo è quindi fatto su feature_branch e solo unendosi al ramo feature_branches quando la funzione è terminata, testata e stabile. Poiché è stabile, può essere usato come palcoscenico. Tagli un ramo develop da release quando sei pronto per il rilascio, vincoli le estremità libere, uniscilo in develop e poi hai la tua nuova build di produzione.

Uno dei tuoi primi ordini di lavoro dopo aver ottenuto questo set up dovrebbe essere quello di unire master in feature_branch * e poi develop di nuovo in develop . Ricorda che master può contenere codice e caratteristiche non testate, quindi fai attenzione quando lo sposti in feature_branch e poi in develop . Una volta eseguita questa operazione, tutti i rami devono contenere lo stesso codice e qualsiasi sviluppo eseguito sul server di produzione viene ora riportato nel "server" di sviluppo.

In questo modello, ogni progetto sarebbe nel proprio repository e quel repository avrebbe un ramo master e master , più develop per qualsiasi lavoro svolto.

MODIFICA, per indirizzare i commenti: Sì, questo è Gitflow.

Questa strategia (o Gitflow in generale) mantiene il sistema esistente a 3 livelli (produzione, gestione temporanea, sviluppo) con un chiaro percorso di unione dallo sviluppo alla produzione. L'importazione delle basi di codice in questo modo consente inoltre di sincronizzare le filiali mantenendo lo status quo in produzione, almeno fino a quando le unioni possono essere testate. Questo porta a pochi obiettivi: ottiene il codice nel controllo del codice sorgente, sincronizza le diverse basi di codice e le unisce (quindi non ci sono più correzioni di bug nella produzione ma non sviluppo) e fornisce un buon processo da utilizzare in avanti (un processo ben definito e utilizzato da molte persone / squadre / aziende). Se l'OP rileva che Gitflow non è adatto per i suoi progetti / team / società mentre lo usa / l'azienda cresce, allora è facile cambiare in seguito - ma il punto critico è che tutto è nel controllo del codice sorgente e lo sviluppo è in corso fatto sul ramo giusto.

* Potresti voler tagliare un altro ramo di funzione e rimuovere qualsiasi nuova ovvia funzionalità, e unire quel ramo in feature_branches (e poi in develop ). Questo ti impedisce di testare nuove funzionalità in aggiunta a tutti gli altri test che farai.

Raccomanderò il codice staging come la migliore base per l'importazione iniziale. Questo perché ci sono cambiamenti in production che non sono in staging , a causa delle correzioni rapide, ma molto meno se qualche variazione in staging non è in production . Allo stesso modo ci sono cambiamenti in development che non sono in staging , a causa delle nuove funzionalità, ma probabilmente molto meno se qualche variazione in staging non è in development .

Nota, non vuoi staging per essere la tua linea di base dopo l'importazione iniziale. Questa è solo una situazione temporanea a causa di modifiche non monitorate in precedenza. Le operazioni di diramazione vanno molto più agevolmente se si modificano aggiungendo piuttosto che rimuovendole. Dopo l'importazione iniziale, passa a qualsiasi modello di branching che si adatta meglio alle tue esigenze.

Quindi, controlla il tuo codice staging in un ramo staging , quindi crea un git checkout -b master staging per creare il tuo ramo master e controlla il tuo codice di produzione. Quindi crea un git checkout -b development staging per creare il tuo ramo development e controlla il tuo codice di sviluppo lì dentro.

Ora controlla il tuo ramo development e unisci master in . Ciò ti consentirà di risolvere la probabile quantità enorme di conflitti di merge mantenendo al contempo master come record di ciò che è effettivamente in produzione. development ora contiene tutte le modifiche da ogni ambiente. Ora puoi passare a qualsiasi modello di ramificazione che ti si addice meglio.

È una buona idea avere la storia. Creerei il repository (o uno per ogni prodotto) dall'ambiente più stabile. Crea filiali o diff per gli altri.

Ad un livello elevato:

1. Crea un nuovo repository
2. Da una copia di lavoro basata sulla produzione: aggiungi tutto, conferma e spinge
3. Checkout master in una nuova directory
4. Per ogni ambiente aggiuntivo XYZ
   1. Crea ramo Archive-XYZ
   2. Sostituisci tutto con XYZ sorgente (tranne .git)
   3. aggiungi tutto, conferma e spinge

In alternativa, se sei scettico sul valore di questo, git diff > XYZ.diff invece di commettere e spingere e archiviare i diff.

In ogni caso, dovresti terminare in uno stato in cui puoi facilmente confrontare il codice che hai eseguito in ogni ambiente, che puoi utilizzare per stabilirti su un singolo punto di partenza per ogni progetto. E se qualcosa si rompe, teoricamente sarai in grado di confrontare le tue modifiche con uno qualsiasi dei tre ambienti.