Qual è il miglior flusso di lavoro Git per lavorare con un progetto open source con modifiche specifiche del datore di lavoro?

Al mio attuale datore di lavoro, stiamo usando un progetto open source ospitato su Github come componente della nostra applicazione. Ho lavorato a questo progetto sia per aggiungere alcune funzionalità di cui abbiamo bisogno sia per integrarlo con i nostri sistemi di compilazione. Il mio manager e io siamo d'accordo sul fatto che vorremmo inviare tutto il nostro lavoro su questo componente quanto è ragionevole tornare al progetto open source. La mia domanda è su quale sia il miglior flusso di lavoro / tecnica per mantenere il mio impegno Git in modo tale da poter facilmente separare le cose che hanno senso aggiungere al progetto open source - correzioni di bug e nuove funzionalità che sono sufficientemente generali - da elementi specifici del nostro progetto, come posizioni di costruzione e costanti dell'applicazione.

Quello che ho fatto finora è mantenere un ramo Git privato in cui applico tutti i miei cambiamenti, con un'adeguata granularità. Quindi uso cherry-pickper aggiungere i commit open source al ramo master e inoltrarli a Github.

Sembra che dovrei usare la fusione per farlo, in modo da non continuare a creare commit separati con contenuti identici, ma non sono sicuro di come farlo, escludendo gli commit specifici dell'azienda e mantenendo un flusso di lavoro ragionevole.

Ad esempio, suppongo che potrei commettere cose open source su cose master e specifiche dell'azienda sul ramo privato, e quindi unire il master in quel ramo secondo necessità, lasciando il ramo master che punta al commit prima della fusione, in modo tale da poter commetti di nuovo cose open source e poi unisci nuovamente. Ciò che sembra imbarazzante in questo flusso di lavoro è che avrei bisogno di decidere in anticipo per tutto ciò che faccio su quale ramo apparteneva, lavorare su quello che sembrava un completamento, quindi impegnarlo e unirmi prima del test. Una delle cose che mi piace di più di Git è quanto sia facile fare tutto ciò di cui hai bisogno per far funzionare la tua applicazione, e poi decidere in seguito come e dove impegnare le tue modifiche. Per quanto ne so, se sei attualmente in una filiale e hai fatto un po 'di lavoro, lì'

Quello che sto facendo è un flusso di lavoro ragionevole per i contributi a lungo termine? Qualcuno può raccomandare un flusso di lavoro diverso che potrebbe essere migliore e perché è meglio?

Ecco una strategia che potrebbe funzionare per te:

Crea 2 repository git privati, con un repository per lavoro aziendale e l'altro è il repository generale (mi piacerebbe impegnare nuovamente).

Per far funzionare questo sistema, è necessario farlo (che considero la strategia più importante): definire ciò che è "generale" e che può essere utilizzato da tutti gli altri membri della comunità

Con questa definizione, è possibile separare ciò che si impegnerà nuovamente e ciò che non è necessario impegnare.

Ha senso che ciò che codifichi per la comunità sia in una forma generale, poiché un pezzo di codice troppo specifico non gioverà a nessuno (e potrebbe anche non arrivare al ramo principale).

Ora che sai cosa stai per impegnare nella community, puoi fare la maggior parte del lavoro di "restituzione" nel repository ad essa dedicato. Quindi trasferisci semplicemente quel repository sul tuo repository basato sul lavoro e svolgi qualsiasi lavoro specifico sul lavoro.

Ho il sospetto che trascorrerai molto più tempo nel repository "restituire", quindi ricorda di fornire commenti preziosi, ecc. (Forse anche documentazione) per le persone che userebbero quel progetto in futuro.

Credo anche che Git possa fare molto di più di quanto pensi. Ho visto questo video su Vimeo: http://vimeo.com/46010208 e lei ha fatto un ottimo lavoro nel spiegare molte cose stravaganti che Git può fare.

La mia strategia non è l'unica là fuori, ma può sicuramente essere un punto di partenza per te di pensare a 1 adatto a te.

A seconda della natura della base di codice open-source e di ciò che è necessario ottenere apportando modifiche, è possibile ottenere un sacco di chilometraggio separando le preoccupazioni. Nel fork del progetto, aggiungi solo le cose che intendi contribuire all'originale. Aggiungi hook o punti di estensione per consentirti di svolgere il lavoro della tua azienda che non sarà condiviso.

In questo modo non dovrai mai preoccuparti di dividere o decidere in anticipo cosa condividere e cosa non condividere. Poiché hai aggiunto flessibilità al progetto originale, in seguito puoi sempre scegliere di condividere alcune parti del lavoro della tua azienda.