Applicazione di commit in un altro ramo senza unione

Puoi avere tre rami invece di due?

• branch work , con tutto il codice indipendente dalla piattaforma, che è il 99% nel tuo caso;
• branch platform-A con codice specifico per la piattaforma A;
• branch platform-B con codice specifico per piattaforma B.

Il tuo lavoro principale avviene su work branch. Unisci periodicamente le modifiche da esso in platform-A e platform-B , modificando gli aspetti specifici della piattaforma, se necessario.

In questo modo, le cose specifiche della piattaforma A non si infiltrano involontariamente nel codice della piattaforma B e viceversa. Puoi anche facilmente mantenere la maggior parte dei tuoi test indipendenti dalla piattaforma.

Questo sembra un compito per un sistema di build, non un sistema di controllo di versione.

Non penso che la domanda abbia un senso.

In git, ogni repository è essenzialmente un ramo. Non esiste alcuna forma di inclusione del codice che non sia univoca. È necessario sincronizzarli e nel processo, eseguire manualmente l'unione oppure è necessario consentire al software di fondersi automaticamente.

Se le modifiche sono very minori, come solo diversi argomenti della riga di comando, questo dovrebbe essere fatto con i file di configurazione.

Altrimenti, come alluso da @radium, dovresti creare moduli separati, includere tutto nel controllo del codice sorgente e fare in modo che il sistema di generazione determini quale modulo è incluso.

L'uso di Git per mantenere due rami diversi è fragile e soggetto a errori, perché devi sempre ricordare di apportare le modifiche in entrambi i rami.

Puoi usare un .gitignore file per assicurarti che i file di configurazione vengano ignorati da git, salvali da qualche parte nel repo, e avere lo script di compilazione copia il file corretto nella posizione designata.

Ad esempio:

Repo contiene: meta/windows.properties meta/mac.properties

.gitignore file dice di ignorare user.properties

Crea script copia meta/windows.properties o meta/mac.properties a user.properties .

Quindi compilare, creare, eseguire.

Dovresti riuscire a farlo usando le patch. Dai un'occhiata a questo post:

Come creare e applicare patch

e questa domanda SO:

Genera una patch per un commit specifico

Effettuare ricerche su google per patch git fornisce anche molte informazioni.

Questo può essere fatto con git cherry-pick comando, ma è destinato a essere usato con parsimonia. Farne una parte regolare del tuo processo alla fine diventerà doloroso.

Un'opzione leggermente migliore è quella di creare un ramo master con tutto il codice comune, quindi fare in modo che le modifiche personalizzate di ogni configurazione vengano eseguite nei propri rami. Ciò ti consente di unire da master in basso ai singoli rami di configurazione.

Tuttavia, l'opzione migliore è quella di refactoring del codice in modo da poter utilizzare solo un flag di compilazione o un file di configurazione per passare tra le diverse configurazioni. Mantenere due configurazioni in rami separati è ragionevole, ma man mano che le tue esigenze crescono, diventerà poco maneggevole. È meglio mordere il proiettile ora quando è più facile da refactoring.

Ci sono vari modi per farlo con git, come altri hanno messo in evidenza - cherry-picking, introducendo un altro ramo, applicando manualmente le patch, ecc.

Tuttavia, sembra che questo non sia ciò che dovresti davvero fare. Stai gestendo una base di codice che deve essere distribuita su piattaforme diverse; le diverse "versioni" non sono diversi stati di sviluppo dell'albero del codice, ma piuttosto diversi prodotti derivati da esso, a.k.a. build .

Quindi, imposta un sistema di build se non lo hai già fatto (può essere semplice come uno script di shell che esegue alcuni rsync o cp -r jobs). Fai in modo che tu possa passargli un argomento che determina per quale piattaforma costruire, e in base a tale argomento, il sistema di build decide quali file includere nel pacchetto di rilascio. Con solo un po 'di buona struttura, passi un giorno o giù di lì per ottenere gli script di compilazione e poi non preoccuparti mai più.

Ho due rami git con lo stesso codice, ma alcune modifiche minori per supportare piattaforme diverse.

Stai tentando di utilizzare un sistema di controllo delle versioni per risolvere un problema di progettazione.

Non conosco i dettagli dei tuoi sistemi ma questo "piccolo cambiamento per piattaforma" può essere facilmente progettato con un po 'di astrazione e polimorfismo se usi un linguaggio OO. In altri paradigmi, come la programmazione strutturata o funzionale, ci sono altri modi per ottenere il polimorfismo, ma la sua via è posibile.

Se fornisci maggiori dettagli sui tuoi sistemi, puoi ottenere risposte molto migliori.