TL; DR
I file di build o test di Canonical devono sempre essere inclusi nel repository. I file che dovrebbero essere personalizzati da ogni sviluppatore dovrebbero essere inclusi in modo minimalista all'interno del repository, spesso sotto forma di file di esempio.
Motivi per includere un file Guardfile della linea di base Verbatim
I file necessari per creare o testare la base di codice dovrebbero essere inclusi nel repository. Un file Guard contenente le personalizzazioni necessarie per eseguire correttamente la tua suite di test, come gli argomenti relativi a RSpec, potrebbe quindi avere senso come parte integrante del repository. Tuttavia, il file Guardfile dovrebbe non contenere preferenze personali come lo screen clearing o altre personalizzazioni per sviluppatori.
In molti progetti, un Guardfile standard può essere una cosa perfettamente ragionevole da impegnare, a condizione che tutti i membri del team si aspettino di utilizzare la stessa configurazione. Ciò garantirà che le cose "funzionino" solo dopo la clonazione, ma al costo di implementare una configurazione vanilla su tutte le workstation degli sviluppatori.
Motivi per includere un file di esempio per la personalizzazione
Su progetti in cui la personalizzazione del Guardfile non è necessaria, ha senso impegnare direttamente il Guardfile. Tuttavia, su team o progetti in cui il Guardfile in uso può variare tra gli sviluppatori, spesso è meglio eseguire un esempio come Guardfile.example che gli sviluppatori possono quindi copiare in Guardfile prima modificandolo, assicurando che le singole personalizzazioni non vengano trasferite a monte.
Si noti che questo approccio richiede anche che il nome file per le personalizzazioni sia aggiunto al file .gitignore del progetto, o l'equivalente per il proprio SCM di scelta. Generalmente vorrai che vengano apportate modifiche a Guardfile.example per gli utenti futuri, ma non vorrà che venga eseguito il commit di Guardfile di ogni sviluppatore se fanno qualcosa di comune come git add . quando si impegna un nuovo lavoro.
Lo svantaggio dell'approccio basato sui file di esempio è che richiede un passaggio manuale da parte di ogni sviluppatore per configurare correttamente la catena di strumenti prima del primo utilizzo. Ciò aumenta il carico cognitivo del bootstrap del progetto e può essere facilmente dimenticato o trascurato quando si clona un progetto. Anche se il passo è documentato nel tuo readme, o il tuo progetto include una sorta di script di installazione che include una riga come cp Guardfile{.example,} , dovendo rinominare o configurare i file di configurazione specifici degli strumenti come Guardfile o .rspec prima di poter eseguire il test suite correttamente la prima volta può violare il principio di minima sorpresa per i nuovi membri del team.