Invia automaticamente le modifiche a una cartella in un repository git su github?

Question

Ho un repository in cui lavoro.C'è una cartella lì dentro dove inserisco tutto il materiale che voglio rendere open source, quindi è separata dalle parti private.C'è un modo per fare in modo che Git invii automaticamente tutto ciò che è stato memorizzato in quella cartella in un repository github senza che io debba ricordarmi di inviare lì ogni volta i file appena modificati?Voglio spingere l'intero repository in un'altra posizione Github.

Answer 1

Se disponi di un singolo repository in cui le parti sono destinate a essere pubbliche e le parti a essere private, è necessario modificare radicalmente qualcosa nella configurazione del repository.git tiene traccia dei repository completi, quindi puoi rendere un repository pubblico o privato, ma non in parte questo e in parte quello.

Se disponi sia di un repository con i file "pubblici" che di un repository con i file "privati", puoi aggiungere un hook git al repository "pubblico" per inviare automaticamente i commit e mantenere privato il repository privato.

Tuttavia, stai scrivendo che hai un singolo repository contenente sia file "pubblici" che "privati", quindi devi dividerlo in qualcosa di "pubblico" e qualcosa di "privato in qualche modo.

Hai una serie di opzioni per risolvere queste situazioni:

1. Dividi la cartella "pubblica" nel proprio repository che spingerai su GitHub.Questo riscriverà un po' la cronologia della cartella "pubblica".Lo illustrerò più dettagliatamente di seguito.

2. Crea una filiale che riguarda solo la cartella "pubblica" e pubblica solo quella filiale.Ciò è rischioso nella "spinta accidentale, cioè"pubblicare, roba privata" senso, e assolutamente impossibile o almeno abbastanza difficile da fare se hai tutti i commit che toccano sia i file "pubblici" che quelli "privati", quindi vorrei Sconsigliare questa opzione e non scriverò più su di essa.

Per dividere la cartella "pubblica" nel proprio repository, crea un nuovo ramo "pubblico" dal ramo "combinato" e utilizza git filter-branch su di esso per fare in modo che il nuovo ramo "pubblico" contenga solo elementi della cartella "pubblica".La sezione "Esempi" mostra proprio l'esempio --subdirectory-filter corretto).Quindi avrai sia il tuo vecchio ramo "combinato" con sia la cartella "pubblica" che le cose private al suo interno, sia il nuovo ramo "pubblico" con solo la cartella "pubblica".

Tieni presente che ad es.i messaggi di commit nel nuovo ramo "pubblico" potrebbero ancora contenere informazioni "private".Quindi dovresti esaminare tutti i messaggi di commit, scansionarli per informazioni private e possibilmente oscurare tali informazioni private, ad es.con git rebase -i.

Aggiornamento: [La successiva spinta di soltanto il ramo "pubblico" e nient'altro probabilmente non trasferirà altre informazioni, quindi questa pulizia del repository probabilmente non è necessaria.] Se hai bisogno di fare qualche oscuramento, vorrai rimuovere i vecchi rev non oscurati dal repository usando git gc (probabilmente con il --prune=0 E --aggressive opzioni - ma non riesco a trovare la risposta SO con maggiori informazioni a riguardo).

Ora il tuo ramo "pubblico" è pronto per la pubblicazione.Per assicurarti che contenga solo le informazioni "pubbliche", puoi inserirle in un nuovo repository nudo locale vuoto, esaminarne il contenuto per verificare che tutti i riferimenti non abbiano informazioni private.Dopo che sei soddisfatto, puoi inviare il ramo "pubblico" a un nuovo repository vuoto su github.Il repository su github conterrà quindi SOLO il ramo "pubblico", che probabilmente dovresti chiamare "master" sul repository github.

Il tuo repository locale con il ramo "combinato" contiene ancora direttamente informazioni sia pubbliche che private e non ha alcun collegamento con il nuovo repository github "pubblico".

Ora tu Potevo riscrivere la cronologia del ramo "combinato" per contenere solo i bit non pubblici, ma ciò sacrificherebbe tutte le connessioni tra lo stato dei file "pubblici" e "privati" durante tutta la cronologia, quindi le build ripetibili di cose vecchie diventerebbero vicine a impossibile.Pertanto, suggerisco di lasciare intatta la cronologia del ramo "combinato" e di rimuovere semplicemente la cartella "pubblica" da esso in un nuovo commit.

Se l'integrazione tra i tuoi file privati ​​e pubblici è molto stretta e dipendente dalla versione, puoi utilizzare git submodule per aggiungere una versione specifica del repository "pubblico" da github al tuo repository privato.Una nuova cartella del sottomodulo denominata proprio come la precedente cartella "pubblica" ridurrà al minimo le modifiche alle tue cose private, poiché in questo modo tutti i file "pubblici" si troveranno nel loro vecchio percorso.Tieni presente che la cartella del sottomodulo non si aggiornerà automaticamente quando qualcosa viene inviato a github.Potresti aggirare il problema aggiungendo un hook git alla cartella del sottomodulo locale che aggiornerebbe le informazioni del sottomodulo nel repository "combinato".

Se l'integrazione tra i tuoi file privati ​​e pubblici è più flessibile, puoi anche trattare i file pubblici come qualsiasi progetto esterno di terze parti e integrarli nei tuoi file privati ​​nel modo in cui li integrerebbe chiunque altro, ad es.come qualsiasi software esterno da cui dipende il tuo software "privato".

Answer 2

githook a spingere sul commit.