Fino ad ora, abbiamo apportato modifiche al codice localmente senza utilizzare alcun tipo di controllo della versione. Con l'aumento della complessità di questo sito, sta diventando sempre più irresponsabile. Cosa è cambiato e quando? Perché è cambiato? Come possiamo vedere com'era prima nel caso in cui causi problemi che scopriremo solo in seguito?
Ci sono così tante buone ragioni per usare il controllo della versione che è quasi fuori dallo scopo di questa serie, ma basti dire che lo useremo. Risolve tutte le domande che ho delineato sopra.
Nel nostro caso, sto già utilizzando il controllo della versione su CSS-Tricks. Uso Git e ospito il repository su Beanstalk. Beanstalk si occupa della distribuzione del sito tramite FTP. La configurazione è semplicissima. Per CSS-Tricks non ho nemmeno un server di staging, metto tutto direttamente in produzione.
Uso l'app Tower per Mac per lavorare con Git. Se vuoi uno screencast completo su come impostare tutto da zero, l'ho disponibile qui.
Facciamo un piccolo cambiamento e puoi vederlo apparire in Tower come un "dif" (dove puoi vedere quale linea è cambiata e come). Alla fine prendiamo il nostro design statico su cui abbiamo lavorato finora e lo trasformiamo in una sottocartella sul CSS-Tricks.com realmente distribuito, quindi guardalo. Sì, funziona! Bene, per la maggior parte. Ora che il design è in una sottocartella, alcuni collegamenti sono interrotti ma non è un grosso problema.
Dovrei notare che non torno abbastanza spesso per mostrarmi i file di commit su Git nei video futuri. Immagina solo che alla fine di ogni video io rimbalzi su Tower, seleziono gruppi di file pertinenti e li invii con un bel messaggio descrittivo di commit (che è quello che ho effettivamente fatto).
