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

11

Al mio attuale datore di lavoro, stiamo utilizzando un progetto open source ospitato su Github come componente della nostra applicazione. Ho lavorato a questo progetto per aggiungere alcune funzionalità di cui abbiamo bisogno e integrarlo con i nostri sistemi di compilazione. Il mio manager ed io siamo d'accordo sul fatto che vorremmo inviare la maggior parte del nostro lavoro su questa componente come ragionevole per il progetto open-source. La mia domanda riguarda quale sia la migliore tecnica / flusso di lavoro per mantenere il mio Git commesso 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 cose che sono specifiche del nostro progetto, come le posizioni di costruzione e le costanti di applicazione.

Quello che ho fatto finora è mantenere un ramo Git privato in cui commetto tutte le mie modifiche, con granularità appropriata. Quindi utilizzo cherry-pick per aggiungere i commit open source al ramo master e li invio a Github.

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

Ad esempio, suppongo di poter commettere cose open source su elementi master e specifici dell'azienda sul ramo privato, e quindi unire il master in quel ramo secondo necessità, lasciando il ramo master che punta al commit prima dell'unione, ad esempio che potrei impegnarmi di nuovo con le cose aperte su di esso e poi unirmi di nuovo. Ciò che sembra imbarazzante in questo flusso di lavoro è che avrei bisogno di decidere in anticipo per tutto quello che faccio su quale ramo appartenesse, lavorare su quello a quello che sembrava completamento, poi impegnarlo e unirlo prima di testare. Una delle cose che mi piace davvero di Git è quanto sia facile fare tutto ciò che è necessario per far funzionare la tua applicazione, e poi decidere in seguito come e dove trasferire le tue modifiche. Per quanto ne so, se sei attualmente in una filiale e hai qualche lavoro da fare, non c'è un modo semplice per inviare parte di quel lavoro a un altro ramo, dal momento che passare a quel ramo richiederebbe una directory di lavoro pulita.

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

    
posta Mason 17.11.2013 - 20:48
fonte

2 risposte

2

Ecco una strategia che potrebbe funzionare per te:

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

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

Avendo questa definizione, puoi separare ciò che ti impegni e ciò che non hai bisogno di impegnare.

È logico che ciò che si codifica per la comunità sia in una forma generale, in quanto una parte di codice troppo specifica non andrà a vantaggio di nessuno (e potrebbe anche non arrivare al ramo principale).

Ora che sai cosa intendi impegnare per la community, puoi svolgere il lavoro di "restituzione" più dedicato al repository dedicato. Quindi devi semplicemente reinserire il repository sul tuo repository basato sul lavoro e fare tutto il lavoro specifico su quello.

Sospetto che trascorrerai molto più tempo nel repository "give-back", quindi ricordati di fornire commenti preziosi, ecc. (forse anche documentazione) per le persone che utilizzeranno quel progetto in futuro.

Credo anche che git possa fare molto più di quello che pensi. Ho guardato questo video su Vimeo: link e lei ha fatto un ottimo lavoro di spiegazione di molte cose bizzarre che può fare git.

La mia strategia non è l'unica là fuori, ma può sicuramente essere un punto di partenza per farti pensare a 1 che ti si addice in modo specifico.

    
risposta data 18.11.2013 - 21:32
fonte
1

A seconda della natura della base di codice open-source e di ciò che è necessario ottenere apportando modifiche, è possibile che si ottenga molto chilometraggio separando le preoccupazioni. Nel tuo fork del progetto, solo aggiungi cose che intendi contribuire di nuovo all'originale. Aggiungi ganci o punti di estensione per permetterti di svolgere attività aziendali che non saranno condivise.

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, potresti sempre scegliere di condividere alcune parti della tua azienda in un secondo momento.

    
risposta data 22.11.2013 - 07:32
fonte

Leggi altre domande sui tag