Ecco il problema e il modo in cui attualmente lo gestiamo al lavoro.
Abbiamo una ricetta buildout che recupera più repository git. A volte, è necessario patch di un modulo da un repository che non possediamo (repository pubblico). Nella mia precedente posizione in un'azienda diversa, abbiamo utilizzato il fork di tutti i repository pubblici e il push delle patch in diversi rami. Funziona bene, ma in alcuni casi è molto più difficile da mantenere e, a volte, le patch sono davvero specifiche per un particolare client, quindi diventa difficile capire quali rami sono rilevanti e bifare oltre 50 repository non è particolarmente facile da gestire se devi dare il permesso di spingere agli sviluppatori. Allo stesso tempo, siamo riusciti a correggere i file che potevano essere applicati direttamente senza dover forgiare alcun repository.
Al mio attuale lavoro, ho deciso di limitarmi a correggere i file perché semplifica il processo. Applicare tecnicamente una patch e unire un ramo è praticamente la stessa cosa.
Le patch sono memorizzate su un repository per client e applicate nel processo di compilazione. Poiché con il recupero di più repository, alcune patch devono essere applicate su projectA e altre su projectB ...
In questo momento, sto scrivendo ogni singola patch che deve essere applicata nel file di configurazione build, ma mi chiedevo se c'era un modo per renderlo meno accoppiato con la configurazione.
Come invece di applicare una patch, applicherei un set di patch che sarebbe più vicino a un'unione che può applicare più "commit". Ma il set di patch dovrebbe essere in grado di applicare patch in più directory / repository. Le patch vengono generalmente create per il repository specifico utilizzando git format patch .