Come posso iniziare a usare Git per basi di codice diverse da server diversi?

Background: Di recente ho ereditato una serie di progetti nella mia azienda e sto cercando di risolvere alcuni problemi fondamentali con il modo in cui sono stati gestiti. Vale a dire, i precedenti sviluppatori (che non sono più con l'azienda) non stavano usando alcuna forma di controllo del codice sorgente, avevano fatto poca documentazione e non avevano in realtà buoni processi di sviluppo.

Quindi ora ho tre server di progetti (sviluppo, gestione temporanea, produzione) che consistono principalmente in siti Web e applicazioni e strumenti creati per applicazioni e API di terze parti che utilizziamo, fino a archivi di script SQL e altre cose. Il mio primo pensiero è stato quello di inserire tutto questo in Git prima che vengano apportate modifiche e correzioni, ma sto facendo fatica a trovare il modo migliore per farlo.

Gran parte dello sviluppo precedente è stato effettuato direttamente sui server di produzione, il che ha creato una divisione tra la base di codici di ciascun server. Non è immediatamente chiaro dove si trovano tutte le differenze: sto vedendo correzioni di bug sul lato della produzione che non sono riportati sullo sviluppo / stadiazione, così come nuove funzionalità sullo sviluppo che non sono state spostate verso la stadiazione / produzione .

Domanda: Quale sarebbe il modo migliore per me di organizzare e spostare questi in Git? Come strutturerei i miei repository / filiali per adattarsi alle differenze nel codice?

Ho considerato lo sviluppo continuo da cloni del codice del server di produzione e mantenendo le basi di codice di sviluppo / gestione temporanea come riferimento storico. Questo potrebbe potenzialmente essere un punto di partenza, considerando che non so comunque nulla del codice di sviluppo / messa in scena? Potrei semplicemente creare repository dei server di produzione per ogni sito Web, strumento, set di script, ecc., Creare rami per il codice di sviluppo / staging esistente e qualsiasi nuovo sviluppo deriverebbe dalla base di codice del server di produzione. ha senso?

Spingi la roba di produzione nel masterramo di un nuovo repository. Creare un developramo da quello e quindi unire il server di gestione temporanea in esso. Potresti finire con conflitti che devono essere risolti. Una volta che questi sono risolti, creare un altro feature_branchda develope unire il server di sviluppo in esso. Risolvi eventuali conflitti.

Questo ti lascia con 3 rami, che rappresentano i tuoi ambienti di produzione, messa in scena e sviluppo. Produzione -> master, messa in scena -> develop, sviluppo -> feature_branch. Tutto lo sviluppo viene quindi eseguito feature_branchese unito al developramo solo quando la funzionalità viene eseguita, testata e stabile. Poiché è stabile, può essere utilizzato come messa in scena. Taglia un releaseramo da developquando sei pronto per il rilascio, lega tutte le estremità libere, uniscilo in master, e poi hai la tua nuova build di produzione.

Uno dei tuoi primi ordini di attività dopo aver ottenuto questa configurazione dovrebbe essere quello di unire feature_branchnuovamente develop* in , e poi di developnuovo in master. Tieni presente che feature_branchpotrebbero contenere codice e funzionalità non testati, quindi fai attenzione quando li unisci in develope poi master. Una volta fatto ciò, tutti i rami dovrebbero contenere lo stesso codice e qualsiasi sviluppo che è stato fatto sul server di produzione è ora riportato nel "server" di sviluppo.

In questo modello, ogni progetto sarebbe nel proprio repository e quel repository avrebbe un mastere un developramo, oltre feature_branchesa qualsiasi lavoro svolto.

EDIT, per rispondere ai commenti: Sì, questo è Gitflow.

Questa strategia (o Gitflow in generale) mantiene l'attuale sistema a 3 livelli (produzione, messa in scena, sviluppo) con un chiaro percorso di unione dallo sviluppo alla produzione. L'importazione dei codebase in questo modo consente anche di sincronizzare i rami mantenendo lo status quo in produzione, almeno fino a quando le fusioni non possono essere testate. Questo raggiunge alcuni obiettivi: ottiene il codice nel controllo del codice sorgente, sincronizza e unisce i diversi codebase (quindi non ci sono più correzioni di bug nella produzione ma non nello sviluppo) e fornisce un buon processo da usare in futuro (un processo ben definito e utilizzato da molte persone / team / aziende). Se l'OP rileva che Gitflow non è adatto ai suoi progetti / team / società mentre lo utilizza / l'azienda cresce, allora "

* Potresti voler tagliare un altro ramo di funzionalità e rimuovere eventuali nuove funzionalità ovvie, e unire quel ramo in develop(e poi in master). Questo ti impedisce di dover testare nuove funzionalità in aggiunta a tutti gli altri test che farai.

Raccomanderò il stagingcodice come migliore base per l'importazione iniziale. Questo perché ci sono cambiamenti in productionche non sono staging, a causa delle difficoltà calde, ma molto meno se eventuali modifiche stagingche non sono production. Allo stesso modo ci sono cambiamenti in developmentche non sono in staging, a causa delle nuove funzioni, ma probabilmente molto meno se eventuali modifiche stagingche non sono development.

Nota, non vuoi stagingessere 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 filiale vanno molto più agevolmente se si aggiungono modifiche anziché rimuoverle. Dopo l'importazione iniziale, passa al modello di diramazione più adatto alle tue esigenze e per il futuro.

Quindi, controlla il tuo stagingcodice in un stagingramo, quindi fai un git checkout -b master stagingper creare il tuo masterramo e controlla il tuo codice di produzione lì. Quindi fai un git checkout -b development stagingper creare il tuo developmentramo e controlla il tuo codice di sviluppo lì dentro.

Ora controlla il tuo developmentramo ed master entra in esso. Ciò ti consentirà di risolvere la probabile enorme quantità di conflitti di unione pur mantenendo masteruna registrazione di ciò che è effettivamente in produzione. developmentora contiene tutte le modifiche da ogni ambiente. Ora puoi passare al modello di ramificazione più adatto a te.

È una buona idea avere la storia. Vorrei creare il repository (o uno per ciascun prodotto) dall'ambiente più stabile. Crea rami o differenze per gli altri.

Ad alto livello:

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

In alternativa, se sei scettico sul valore di questo, git diff > XYZ.diffinvece di impegnarti effettivamente e spingere, e archiviare le differenze.

Ad ogni modo, dovresti finire in uno stato in cui puoi facilmente confrontare il codice che hai in esecuzione in ciascun ambiente, che puoi usare per stabilirti su un singolo punto di partenza per ciascun progetto. E, se qualcosa si rompe, teoricamente sarai in grado di confrontare le tue modifiche con uno qualsiasi dei tre ambienti.