Corretto flusso di lavoro Git per sistema operativo combinato e codice privato?

Question

Ho un progetto closed source che è stato creato sul mio framework open source. Voglio sapere come dovrei strutturare il mio flusso di lavoro. Di seguito è la mia ipotesi migliore usando git con i sottomoduli.

1. creo un repo quadro sul pubblico github con sottomoduli che sono repo git separati.
2. Acquisto un account "micro" su github ($ 7), quindi I può avere un repository privato.
3. Creare un repository privato e clonare il repository pubblico.

Da qui posso apportare modifiche a:

1. Il mio codice privato e spingere al mio repo privato su github
2. Il codice del framework pubblico e spingere al mio repo github privato e quindi inviare un pull richiesta dal quadro pubblico ..? O come funzionerebbe?

Come gestisco un repository che contiene codice e sottomoduli privati ​​e pubblici. In questo momento sembra che devo solo mantenere due codebase separati per raggiungere questo obiettivo.

Sto cercando la migliore risposta che possa aiutare qualcuno abbastanza nuovo a git a semplificare il processo di lavoro su un codebase che è metà open source e metà privato. Una cosa buona è che ogni cartella è privata o pubblica, quindi non c'è da preoccuparsi di avere file privati ​​e pubblici insieme da qualche parte - eppure alcune delle cartelle private potrebbero essere pubbliche!

Un altro esempio che potrei dare sarebbe utilizzare zendframework per creare il sito della tua azienda privata pur essendo in grado di eseguire pull ogni giorno (e magari patch push) sul repository zend. E inoltre tira e spinge il tuo sito privato all'interno di zendframework.

Per esempio, immaginate una struttura di directory simile a questo:

/private_folder 
/public 
     /public_folder 
     /public_folder2 
     /private_folder 

Forse sto chiedendo due molto per gestire tutti in una directory uniti pronti contro termine. Forse non c'è un modo semplice per farlo e dovrei separarli e fare tutte le patch pubbliche in una sola e poi entrare nel mio repository privato. Ovviamente, questo significa che se mi trovo nel mezzo di lavorare su un codice privato, dovrò lasciare quel repository e aprire quello pubblico e modificare il codice patch, quindi tornare a quello privato, unire e quindi continuare a lavorare sul codice privato.

Answer 1

Si consiglia di non utilizzare i sottomoduli git, ma 2 repository diversi che non sono connessi su github.

È possibile creare la relazione tra di loro utilizzando i collegamenti simbolici sulle copie ritirate, che è semplice e di base. I collegamenti simbolici devono essere creati solo una volta per posizione (produzione, sviluppo, collaboratori).

Il vantaggio è che nessuno deve fare lo sforzo extra per apprendere e mantenere i sottomoduli git ed evitare il rischio e la complessità che comporta.

Potrebbe essere fatto mantenendo una copia di lavoro del sistema operativo e del repo git privato da qualche parte sul computer locale:

/repos/myproject-os 
/repos/myproject-priv 

allora si potrebbe creare creare la struttura della directory in cui il progetto in realtà vivrà e essere lavorato da qualche altra parte su questa macchina (non all'interno del/repository/albero) e creare symblinks per le sottodirectory che si utilizza:

ln -s /repos/myproject-os/dir1 /wrk/myproject/base/dir1 
ln -s /repos/myproject-os/dir2 /wrk/myproject/base/dir2 
ln -s /repos/myproject-priv/dir1 /wrk/myproject/base/dir3 
ln -s /repos/myproject-priv/dir2 /wrk/myproject/base/someother/dir4 
mkdir /wrk/myproject/base/config 
mkdir /wrk/myproject/base/tmp 

in questo modo si ha la struttura di repository sempre pulito e possibile combinare e organizzare le directory da entrambi riposano ti piace come vuoi e hai anche uno spazio per le configurazioni locali o i file temporanei che non vanno nei repository.

Si farebbe il commit git e tutto da/repos/tree e il progetto verrebbe eseguito e si modificheranno i file da/wrk/tree. Si noti che il file .git in cui risiedono i dati git sarebbe non disponibile da/wrk/tree, perché si collegano solo sottodirectory (o eventualmente singoli file dalla directory principale).

Part2: Si dice che si desidera assicurarsi di non spingere accidentalmente codice privato nell'archivio pubblico. Si potrebbe impostare un repository git aggiuntivo tra il repository del sistema operativo di lavoro e il repository GitHub, diciamo che lo metti in/repos/gatekeeper, allora il vostro albero assomiglia a questo:

/repos/gatekeeper/myproject-os 
/repos/myproject-os 
/repos/myproject-priv 

Ogni volta che si preme da/repos/myproject-os va a/repos/gatekeeper/myproject-os. Ma da/repos/myproject-priv si spinge direttamente al repository Github privato.

In questo modo si ha lo stesso flusso di lavoro in/repos/myproject-os e/repos/myproject-priv e non è necessario preoccuparsi così tanto. Di volta in volta quando si desidera trasferire le modifiche alla base di codice del sistema operativo reale, si accede a/repos/gatekeeper/myproject-os e si passa da lì a github.

Prima di ciò, è possibile eseguire una revisione del codice aggiuntiva e osservare le differenze in modo da essere certi che solo ciò che si desidera venga reso pubblico.

Se si desidera una protezione aggiuntiva, il/repos/gatekeeper/myproject-os potrebbe trovarsi su una macchina diversa o in una posizione diversa.

Answer 2

È possibile avere un ramo "pubblico" e "privato" nel proprio repository locale. Quando si preme, ogni ramo viene trasferito in un repository remoto separato (cercare la sintassi 'git push'). Quindi, puoi liberamente unire da pubblico a privato.

Sono sicuro che c'è un modo per unire le modifiche selezionate da privato a pubblico, anche se dovrei cercarlo.

Answer 3

Fare il repo pubblico un sottomodulo all'interno del privato. Quando spingi, ricorda che devi spingerli entrambi. Ricorda inoltre di controllare il sottomodulo stesso nel repository privato, in modo da tenere traccia delle revisioni del sottomodulo che sta utilizzando.

Answer 4

git submodules consente di definire una configurazione (vedere this question), ovvero un riferimento a un commit di un altro componente (in un altro repository).

È possibile sviluppare entrambi i codici (il proprio e i sottomoduli) all'interno dello stesso repository, ma quando si parla di più directory private all'interno del proprio codice pubblico, viene richiesto un subtree merge strategy.
Ti permetterà di considerare le tue directory (quelle private e pubbliche) come un albero di lavoro naturale.

E per gestire al meglio il tira e molla di parti del tuo repo globale per uno privato, mi sento di raccomandare il git subtree script tool.

Answer 5

In sintesi, vi consiglio questo flusso di lavoro:

1. mantenere le cose semplici; avere una copia di lavoro per ogni repository (non utilizzare moduli Git)
2. utilizzare gli strumenti del linguaggio per confezionare il vostro quadro
3. script di installazione o utensili luce per rendere contesto di commutazione rapida o automatica

I' ho usato i sottomoduli git in passato. Non penso che siano adatti per il tuo caso d'uso. I grandi aspetti negativi che saltano fuori di me sono:

• Aiuta a mangiare la pappa del cane quando si costruisce (o estratto) un quadro. Ti aspetti che i tuoi utenti del framework installino anche i sottomoduli git quando usano il tuo framework? Sto indovinando no.
• Esiste il rischio di pubblicare accidentalmente il codice sorgente privato nel framework open source.
• I sottomoduli Git sono migliorati un bel po 'nell'ultimo anno circa, ma sono ancora relativamente poco compresi. Anche i nervosismi competenti possono lottare con i sottomoduli.

Ecco una domanda secondaria che ammetto non è così chiara: "Quale flusso di lavoro rende più facile il rimbalzo avanti e indietro tra il framework OSS e il progetto privato?"

• C'è un certo fascino per utilizzando moduli e avere entrambi i progetti in un unico albero. Questo ti velocizzerà forse nel tuo editing di testo, ma probabilmente ti rallenterà (o causerà più errori del solito) quando si tratta di fare commit e spingere.

• C'è un certo fascino nel separare i progetti. L'interruttore di contesto (da una finestra di un editor di testo a un altro) può aiutare a ricordare che il progetto OSS è destinato al consumo pubblico. Ad esempio, può aiutarti a disciplinarti a non interrompere la retrocompatibilità e a mantenere un buon log delle modifiche. Commettere e spingere sarà facile in relazione all'alternativa del sottomodulo.

Una volta che hai deciso le tue copie di lavoro, vorrai capire il tuo flusso di lavoro quotidiano. Dipenderà ovviamente dalla tua lingua. (In Ruby, ad esempio, potresti impacchettare il tuo framework OSS come un gioiello, costruirlo e poi far dipendere il tuo codice privato.) Qualunque cosa tu scelga, imposta alcuni script (o scorciatoie dell'editor forse) per aiutarti a costruire le tue librerie (o pacchetti) rapidamente, forse anche automaticamente quando i file cambiano, in modo da poter rimbalzare tra la struttura e il progetto senza sforzo.

Answer 6

Ce ne sono due approccio qui:

1. si potrebbe usare ramo dello stesso repository git. Nel tuo repository privato crea un ramo con un riferimento al tuo repository pubblico e gestisci entrambi in questo modo.

2. Se i componenti che utilizzano nel progetto privato sono sottoprogetti di materiale pubblico, è necessario utilizzare i sottomoduli. La gestione del sottomodulo è in una fase di git alla versione 1.6.6, ma potrebbe essere utile come sottoprogetto.

Che cosa è che mi sembra non si può perdere se il quale omaggio progetto per ogni progetto, quindi se avete chiaro, allora non importa ciò che si sceglie che funzionerà !!!!!!. Oltre a git è facile.