Contrassegna il file come "impossibile" con Git

41

Voglio mostrare alcuni dei miei lavori caricandoli sul mio account GitHub. Tuttavia, ci sono alcuni file che contengono password, come le connessioni al database.

Esiste un modo per contrassegnare un file come impossibile con Git in modo che non possa apparire su GitHub?

git github

— Adam Carter
fonte

1

Suggerimento tangenziale: questo potrebbe non essere applicabile su tutte le piattaforme, dal momento che alcuni sono molto sposati con i file di configurazione, ma potresti considerare di seguire l'approccio 12factor per mantenere questi parametri nell'ambiente: 12factor.net/config . Cioè, il codice dell'applicazione non deve mai assumere la presenza di un file di configurazione. (A differenza di uno script di avvio privato che li imposta, ma non lascia mai la tua macchina locale.)

— millimoose,

1

Se li commetti accidentalmente, assicurati di rimuoverli dalla cronologia completamente git (altre domande spiegheranno come) perché anche se la elimini e la ignori, la vecchia versione impegnata rimarrà nella cronologia e sarà visibile su Github.

— curiousdannii,

3

Nota che tutte le risposte non rispondono davvero alla tua domanda. Non rendono il file impossibile, ma semplicemente configurano git in modo che lo ignori di default. Ma se si inserisce accidentalmente quel nome file in una riga di comando git, si può finire per commetterlo anche se corrisponde a un modello in .gitignore. AFAIK non esiste un modo completo al 100% di dire gitper evitare di salvare un file specifico in tutti i casi. Anche se questo può essere visto come una funzionalità ... che consente comandi espliciti per sovrascrivere le configurazioni generiche.

— Bakuriu,

È possibile rimuovere le password codificate e passare a un'alternativa più sicura. Successivamente è possibile cambiare le password del database. Le vecchie password sono ancora all'interno delle commit ma sono obsolete quando qualcuno in grado di te è in grado di leggerle. Sono abbastanza sicuro che non puoi cambiare un commit una volta che è già stato creato.

— BlueWizard,

3

Oltre a quanto affermato da @curiousdannii, GitHub ha un'intera pagina che discute su come rimuovere i dati sensibili che hai commesso accidentalmente. Tra le altre cose, questa pagina dice di cambiare le password e le chiavi che hai pubblicato accidentalmente. help.github.com/articles/remove-sensitive-data

— Kevin -

67

Esiste un modo per contrassegnare un file come impossibile con Git in modo che non possa apparire su GitHub?

Innanzitutto, non è possibile avere alcuni file e commit visibili nel repository Git locale, ma in qualche modo non visualizzabili in GitHub; se hai un file impegnato in Git, questo verrà mostrato in GitHub.

In secondo luogo, non esiste un modo semplice e pratico per contrassegnare un singolo file come "inconfondibile". Ma esiste sicuramente un modo per ignorare un file in un repository Git: aggiungendo i file, incluso il relativo percorso se necessario — in un .gitignorefile :

Un .gitignorefile specifica file intenzionalmente non tracciati che Git dovrebbe ignorare. I file già tracciati da Git non sono interessati; vedere le NOTE di seguito per i dettagli.

La creazione di una base .gitignoreè abbastanza semplice poiché è solo un file di testo semplice. Quindi, per esempio, se avessi un config.phpfile nella tua radice lo faresti; supponendo che tu stia utilizzando PHP ma il concetto si applica a qualsiasi configurazione. Inoltre sto usando Nano come mio editor di testo in questo esempio, ma sentiti libero di usare qualunque editor di testo che usi normalmente per questo:

nano .gitignore

E aggiungi semplicemente quel nome file a quel file:

config.php

Salvalo e ora Git semplicemente ignorerà quel file.

Detto questo, ciò che mi piace fare per setup come questo è mantenere un campione / esempio configu- rato castrato di specifiche sensibili nel repository, quindi ho qualche riferimento su ciò che il formato del file di configurazione è un file chiamato in questo modo:

config.SAMPLE.php

In questo modo sai esattamente come config.phpimpostare il file config.SAMPLE.phpe puoi assicurarti che config.phpGit non tocchi mai l'effettivo .

Inoltre, se hai intenzione di mostrare il tuo codice, devi aspettarti che qualcuno proverà a prendere quel codice e implementarlo sul proprio sistema in qualche modo. Ricordate, non siamo voi e senza un file di configurazione di esempio nel vostro repository, la gente non capirà davvero come implementare il codice da soli. Diamine, potrebbero anche pensare di non essere competenti perché non hai fornito un esempio di configurazione di base.

— JakeGould
fonte

11

+1 per la risposta corretta e suggerimento di un file di configurazione di esempio. Ci sono alcune biblioteche come Figaro per Ruby che ti spingono in questa direzione. Dovresti avere un file di esempio impegnato con valori simili a valori reali in modo che la persona che guarda il tuo codice sappia come dovrebbe essere l'ambiente. Alcune piattaforme, come Heroku, usano variabili d'ambiente, quindi potresti impostare la tua configurazione su qualcosa come database_url = Environment.DATABASE_URLe lasciare un commento sopra come # postgres://username:password@localhost/dbname.

— Chris Cirefice,

@ChrisCirefice Grazie! Mi stupisce sempre che nascano nuovi "strumenti" che dovrebbero ricordare l'ovvio: se questo codice verrà letto da altri umani, non spiegare come funziona una configurazione fa esattamente cosa? Grazie ancora.

— Jake Gould,

27

È inoltre possibile aggiungere un hook pre-commit per implementare i controlli di integrità. La directory .git/hooksdi ogni repository git ha alcuni script di esempio.

Lo script chiamato pre-commitviene eseguito se esiste prima di ogni commit e un valore di ritorno diverso da zero interrompe il commit.

Ad esempio, potresti avere un semplice script come questo:

#! /bin/sh -e
git ls-files --cached | grep -qx 'filename' && { echo "Excluded file included in the commit" >&2; exit 1; }
exit 0

E se ciò filenamecorrisponde, il commit fallisce.

— Juho Östman
fonte

1

+1 questa è la risposta giusta che impedisce effettivamente l'aggiunta e il commit espliciti del file.

— R ..

In effetti, sebbene la pratica raccomandata non sia quella di fare affidamento su questa prevenzione (cioè usare invece `.gitignore).

— David Z,

2

@R .. Sì e no. Mentre la domanda afferma: "contrassegnare un file come fattibile" lo spirito "impedisce a un file di essere impegnato". La realtà che sta creando .gitignoreè una pratica molto comune e comunemente compresa per chiunque usi Git. Ma uno script pre-commit non è realmente utilizzato dalla maggior parte degli utenti di Git. Richiede una certa conoscenza dell'installazione e richiede alcune vere ragioni per cui un metodo come questo sarebbe preferibile semplicemente usando un .gitignorefile. Ma questo è molto utile per alcuni casi più complessi, ma è sicuramente un concetto che useresti quando sai veramente che devi usarlo.

— Jake Gould,

2

Potrei vederlo usare in situazioni in cui potresti non fidarti al 100% di .gitignore (potresti fare qualcosa di stupido che potrebbe accidentalmente richiedere a Git di aggiungere il file per il commit). O forse qualcun altro potrebbe modificare il file .gitignore (dopo tutto è sotto il controllo della versione). Se hai davvero bisogno di un processo testabile, questo è qualcosa su cui potresti lavorare in tale processo.

— Cort Ammon,

@CortAmmon non si tratta sempre di fiducia. È possibile aggiungere alcune informazioni di debug temporanee e non pubbliche al codice sorgente che non si desidera eseguire il commit ma non è possibile ignorare tale file. Invece vuoi controllarlo prima di impegnarti se non contiene nulla di illegale . Sembra una buona soluzione per questo caso d'uso. E di fatto è così che ho trovato questa domanda perché è il mio caso d'uso.

— t3chb0t,

12

Cosa ha detto @JakeGould. In alcuni casi è anche possibile utilizzare bit di file speciali come skip-worktreeo assume-unchangedche possono essere impostati nel modo seguente; per le differenze tra i due, vedi questa risposta Stack Overflow :

git update-index --assume-unchanged <file>

Che nasconderà quindi ulteriori modifiche a un file già esistente e che potresti usare se vuoi davvero che un file sia lì dopo ogni pull. Ma ti consiglierei di usarlo solo se sai davvero cosa stai facendo.

— PHK
fonte

8

Usa un .gitignorecome ha detto @JakeGould. Inoltre, alcune informazioni correlate:

.gitignoreimpedisce ai file di essere tracciati; se sono già tracciati, utilizzare git rm --cachedper rimuoverli
anche i file / motivi $GIT_DIR/info/excludeverranno ignorati
file / motivi nel file specificato da core.excludes Anche i file dell'utente ~/.gitconfigvengono ignorati.

Vedi la documentazione ufficiale di Git per maggiori dettagli.

— 46and2
fonte

2

Per estendere le risposte di Jake e 46: una buona pratica è avere un'estensione coerente che usi per i file in cui includi informazioni private e che usi .gitignoreper escludere sempre i file con quell'estensione a livello globale (usando il .gitconfigfile come menzionato altrove per averlo sempre ignorato per il tuo utente).

In questo modo, puoi avere ad esempio:

/projectname/mypasswords.exc

e se lo hai escluso a *.exclivello globale, sai che non verrà eseguito il commit, anche se dimentichi di escludere individualmente quel file specifico.

— Joe
fonte