Puoi disabilitare i repository push diretti in base alle tecnologie che stai utilizzando. Prevenire push può essere fatto in qualche modo usando git git, ma se stai usando gitlab / github / bitbucket ... dovrebbe esserci un modo per proteggere i rami.
Se tutti i rami sono protetti e il dev non può creare un nuovo ramo, allora non c'è modo di spingere al repository. In questo modo, dovrai gestire l'app utilizzando "unisci richieste / richieste push" o come viene chiamato.
Non è chiaro che cosa stai effettivamente gestendo in modo che quanto segue potrebbe non essere d'aiuto. Nel mio caso, abbiamo un prodotto principale che viene installato su ogni client, il prodotto principale potrebbe essere installato con versioni diverse. E moduli aggiuntivi possono essere installati sul lato. In entrambi i casi, solitamente la personalizzazione del client viene eseguita installando moduli specifici per i client che estendono i moduli esistenti (inclusi i moduli principali). Nel mio caso, le personalizzazioni per i clienti non si riflettono mai o raramente nel prodotto principale. Se fosse necessario, potremmo semplicemente spostare il modulo nel prodotto principale.
Se un modulo personalizzato è condiviso su più client, potremmo utilizzare rami speciali che vengono uniti nel master di ciascun repository di moduli.
Alla fine, può diventare piuttosto complicato se il codice non è in bolla al ramo principale del repository di ciascun modulo. Nel nostro caso, gran parte del lavoro è realizzato utilizzando buildout per gestire repository, fusioni e dipendenze.
La mia opinione
Gestire le dipendenze usando i repository git dovrebbe essere limitato allo sviluppo anche se sembra più semplice recuperare i repository. Il repository Git può diventare abbastanza grande e talvolta il recupero potrebbe fallire se il repository è grande e la connessione Internet è instabile ... Git non consente il recupero parziale quindi se fallisce al 99%, dovresti comunque riavviare dallo 0% .
Per la distribuzione, penso che abbia più senso che i gestori di pacchetti lo facciano. Esistono e di solito fanno bene il loro lavoro. Il vantaggio dell'utilizzo di un gestore di pacchetti è che non è necessario scaricare l'intera cronologia delle modifiche che potrebbero venire con il modulo. Solitamente i gestori dei pacchetti consentono il download parziale tramite http, quindi è possibile sospendere un aggiornamento in un secondo momento se Internet non funziona. Con un buon gestore di pacchetti, puoi anche ospitare i tuoi server di pacchetti privati per ogni cliente. Qualsiasi modulo simile per ogni cliente può essere inserito su un server centrale e ogni pacchetto personalizzato può essere trasferito su un server di pacchetti per client.
Tutto questo va bene se hai un modo per automatizzare il processo di costruzione del pacchetto e la distribuzione del pacchetto sui loro rispettivi server.
In questo modo se un client fa qualcosa come "aggiornamento del pacchetto", potrebbe controllare sul server client un pacchetto e poi sul server centrale e prendere la versione corretta da questo. Il vecchio pacchetto non deve essere cancellato e il client può eseguire il downgrade della sua configurazione come preferisce.
La mia ipotesi è che è la cosa più bella che qualcuno possa implementare, ma per quanto ne so non esiste un modo standard per farlo. Ho sentito persone farlo con le uova di Python, altre con pacchetti di Debian e così via. Ma ogni implementazione ha i propri problemi ... Come i pacchetti debian non funzioneranno su Windows e distro non debian ... le uova pythong sono piuttosto limitate ai pacchetti python .. npm su javascript e così via. Se avessimo un gestore di pacchetti universale sarebbe semplicemente un gioco da implementare.