Come mantenere un file sorgente "config" non popolato in git repo?

4

Supponiamo di aver creato un widget e decido di condividerlo con Github. In questo progetto di widget, c'è un file di configurazione / preferenze. Devo condividere i valori impostati, in modo che se qualcun altro desidera il proprio widget, saprebbe cosa impostare. Ma non necessariamente voglio o devo condividere le mie impostazioni.

Questo sarebbe un caso in cui alcune / tutte le impostazioni non hanno alcun concetto di 'default' - devono essere tutte esplicitamente impostate dal programmatore.

Pensavo di trovare una risposta in questa domanda , ma in realtà questo (o almeno le sue risposte) sono più focalizzati a mantenere le cose segrete. Non ho bisogno di condividere in sicurezza - non ho bisogno di condividere.

In sostanza, ho bisogno di distribuire Foo := 'Bar' , ma commit / push / share Foo := .

Qual è il modo migliore di gestirlo in Git?

Alcune possibili soluzioni:

  1. Conferma il file non popolato; non includere nei successivi commit con le preferenze impostate. Svantaggio: se aggiungo una nuova impostazione in un secondo momento, è necessario rimuovere tutti i valori per eseguirne il commit e quindi impostarli nuovamente.
  2. Imposta i valori per importazione / inclusione (come applicabile per la lingua) per garantire un errore immediato (e meno confuso di quanto potrebbe essere altrimenti); indicare chiaramente i requisiti in un readme. Svantaggio: nessuno ama gli errori.
  3. Filiali? Non ho mai avuto davvero bisogno di usare più, ma ho un sentimento il modo 'giusto' per fare questo potrebbe essere un ramo 'deploy' non spinto con i valori impostati e non impostati nel ramo "master" premuto; basta gestire i conflitti di fusione che si presentano all'aggiunta di nuove proprietà? Può essere? Lo stesso svantaggio di (1) in realtà, ma forse è la pratica migliore?
posta OJFord 18.07.2015 - 17:33
fonte

3 risposte

4

Vorrei andare con una versione modificata dello scenario 1. Invece di aggiungere il file di configurazione real al repository, aggiungere un file di configurazione prototipo. Quando il widget viene eseguito per la prima volta, rileva se il file di configurazione è presente o meno. Se non presente, rinomina il file prototipo e lo carica. Il file prototipo può avere valori predefiniti (potrebbe non funzionare "ma non bloccare il widget).

Questo ti permetterà di avere il tuo file di configurazione locale (che non è mai stato eseguito, ma probabilmente dovrebbe essere sottoposto a backup) e una versione che può essere pubblicamente spacciata che non contiene le tue informazioni private.

    
risposta data 18.07.2015 - 17:46
fonte
3

Quindi l'idea è: se controllo il tuo repository git, ricevo un modello di file di configurazione, in cui devo inserire i valori corretti, e non puoi sapere quali sarebbero i valori corretti per me. In tal caso, il tuo file di configurazione dovrebbe ovviamente avere un sacco di documentazione, e la costruzione / esecuzione del progetto dovrebbe fallire il prima possibile per me se non apporto le modifiche necessarie. Dovrebbe anche essere difficile per me impegnare il mio file di configurazione fisso in modo che non venga distribuito per errore (per lo stesso motivo per cui non si esegue il commit del proprio file di configurazione).

Vorrei registrare un file modello, assicurarmi che l'intero progetto sia impostato in modo che il file modello non diventi parte della build e aggiungere istruzioni su come creare il file di configurazione corretto e configurare il tuo progetto in modo che il file di configurazione corretto sia necessario per costruire. È possibile impostare git in modo che ignori il file di configurazione.

    
risposta data 19.07.2015 - 01:32
fonte
1

Il mio primo pensiero è: non memorizzare affatto il file di configurazione popolato in git. Inserisci il file non popolato in git e in fase di installazione o prima esecuzione, crea il file popolato in un altro posto. Se la configurazione è specifica per l'utente, questo altro posto sarà in:

  • Windows:% APPDATA%
  • Linux: un file di punti o una cartella di punti nella home directory dell'utente. Qualcosa come ~/.myapp_config
  • Mac OS X: la cartella Libreria dell'utente, probabilmente in una sottodirectory per la tua app.
risposta data 18.07.2015 - 17:46
fonte

Leggi altre domande sui tag