Lavoro con un piccolo team che fino a poco tempo fa non utilizzava il controllo del codice sorgente. Sto lavorando al layout del nostro flusso di lavoro di sviluppo / distribuzione con git. Gradirei e consigli o intuizioni che potresti avere.
Ti risparmio i dettagli ma fondamentalmente utilizziamo il modello di branching del flusso git e la distribuzione con un telecomando puntava a un repository nudo sul server di produzione con un hook post-ricevente. La mia domanda è con un progetto più ampio che abbiamo sviluppato. Questa è un'applicazione che avrà molte istanze che dovranno essere in grado di aggiornare dal ramo master del repository delle applicazioni ma anche avere il proprio set di file univoci (file specifici del progetto front-end).
Sono un po 'perso e penso che potrebbe essere perché ho lo schema di implementazione un po' fuori. Ho sentito molte persone dire "git non è per lo spiegamento" e un numero uguale dice il contrario. Il sistema funziona alla grande per noi che attualmente stiamo spingendo verso il remoto che lo distribuisce in base al gancio di post-ricezione di quel server.
Un'idea di implementazione che abbiamo è quella di avere una lista di rami dal master dell'App che avrà i propri rami "projectA-master" e "projectA-develop" che seguiranno il nostro attuale workflow git. Questo ci porta ad avere MOLTI rami sul repository App originale e questo sembra sbagliato. Per non parlare che non scala bene. Abbiamo solo quattro server previsti per la distribuzione, ma questo metodo è terribile quando diventa 20 o più. È un rompicapo.
master---A---B---C
\ \
\ develop--A--B--C
\
\projectA-master--C--D--E
projectA-develop--C--D--E
Yuck.
Un'altra idea era quella di avere il repository di App per lo sviluppo e gli aggiornamenti e un altro repository (magari App-frontend) che sarebbe specifico per ogni progetto e avere un modello di ramificazione simile sopra solo non nel repository App originale preservando il suo codice e le sue filiali solo allo sviluppo specifico delle app di base. Quindi averli entrambi distribuiti nel server remoto.
master(App)---A---B---C---E---F----G
\ / \___
develop---A---B---C---E----F ___ Live Instance
/
master(App-frontend)---A---B---C---E
\ /
develop---A---B---C----E----F
Anche questo sembra sbagliato.
Ho usato .gitignore per ignorare tutte le directory che sono specifiche del progetto, ma il problema che ho riscontrato era che i miei file FE non venivano controllati dalla fonte sul server remoto, rimanevano non tracciati.
Non so come spingere gli aggiornamenti dal repository principale dell'app e non sovrascrivere i file personalizzati sul livello specifico del progetto (repo del server remoto).
Quindi come gestisci una situazione come questa? Hai un prodotto che avrà molte istanze, ma ogni istanza ha file front-end specifici del cliente. E come viene gestito su larga scala da centinaia a migliaia di istanze e hai ancora bisogno di estendere aggiornamenti / correzioni?
Sono stato in tutto questo e in altri forum e sono diventato molto lontano dal non utilizzare veramente git. Se hai tempo, apprezzerei alcuni suggerimenti di quelli di voi più esperti che possono dirmi cosa sto sbagliando e cosa sto facendo bene.
Grazie mille.