Git: rimuovere le credenziali dal repository

Question

Inizialmente: Questo è (si spera) non duplicato di this o this.

Lo stato corrente: Ho eseguito il commit di un file con credenziali per un database interno nel repository Git. Questo andava bene, perché l'ho usato solo da solo. Poi il mio gruppo ha iniziato a clonare, spingere e tirare in giro in questo progetto. Ora abbiamo diversi repository Git (uno centrale e alcuni sviluppatori).

Il problema: Ora vogliamo fornire l'accesso pubblico al codice sorgente e al repository Git o almeno consentire a Git di gestire i dettagli di altri utenti che contribuiscono al codice.

La domanda: Quale potrebbe essere una buona strategia per

a) rimuovere il file con le credenziali della centrale o da tutti i repository, o

b) istituire un nuovo repository Git come tipo di "interfaccia" con il mondo esterno?

Se si sceglie (b), come possiamo comunicare facilmente le modifiche al repository principale?

A causa della distribuzione già diffusa, ci piacerebbe davvero non fare uno git rebase o uno git filter-branch su ogni singolo repository corrente.

Answer 1

Siamo spiacenti, ma sei bloccato con l'esecuzione di git filter-branch se desideri eliminare le credenziali dal repository principale. Vedi Removing sensitive data, scritto dalla gente di GitHub.

A causa della progettazione di Git, non c'è modo di forzare i cloni esistenti a eliminare il file dalle rispettive cronologie.

Si potrebbe sterilizzare un singolo ramo e renderlo la base per lo sviluppo futuro:

$ git checkout -b old-master master 
$ git filter-branch ... master 

Ora avresti bisogno di spingere il maestro igienizzato ad un nuovo repo che contiene solo il maestro pulita:

$ git push new-central master 

I repository esistenti possono aggiungere il nuovo telecomando e le modifiche git cherry-pick dalle loro vecchie filiali al nuovo master pulito, se necessario.

Per il nuovo repository, mettere una sorta di barriera in atto per impedire a qualcuno di spingere dati sensibili ad esso in modo da non avere lo stesso problema tutto da capo. Questa barriera potrebbe essere un essere umano che controlla il nuovo repository centrale e rivede tutte le patch per decidere cosa va.

Answer 2

Non c'è modo di fare a) senza usare rebase o branch-branch. Ma direi che probabilmente è MEGLIO farlo in questo modo ora, piuttosto che dover lottare con la storia nascosta per sempre. Immagino che b) potrebbe essere fatto dividendo la cronologia dopo un commit che rimuove le credenziali. Il risultato sarebbe praticamente due storie, collocate in due repository diversi; uno prima del clean-up, e uno che "riavvia" subito dopo. La cronologia di questi due repos può essere connessa tramite graft-points nei repository di coloro che devono raggiungere la vecchia cronologia.

In entrambi i casi, dovrete affrontare un intero carico di sh * t, e consiglierei di andare a) e ramo filtro anche se è molto lavoro.

Answer 3

Basta cambiare la password per il database interno e qualsiasi altro servizio con la stessa password. (e lo stesso per qualsiasi altra password che esisteva da qualche parte nella tua cronologia).

Answer 4

Quindi, abbiamo finito e mi piacerebbe condividere come abbiamo fatto finalmente.

Eravamo nella posizione fortunata che nessuno aveva un ramo personalizzato in un determinato momento. Quindi, in sostanza, ciò che abbiamo fatto è stato che tutti hanno spinto per l'ultima volta le loro cose nel repository centrale.

Quindi abbiamo usato filter-branch come descritto dall'equipaggio GitHub su di esso. Avevamo quindi un repository centrale chiaro.

Infine (e questo ha funzionato solo perché nessuno aveva una filiale locale come accennato) abbiamo eliminato i nostri repository locali e ne abbiamo clonati di nuovi da quello centrale ora pulito.

Per dirla in breve: in questo modo è stata una procedura abbastanza rapida e indolore. Non elegante, ma ha funzionato.