Jusqu'à présent, nous avons apporté des modifications de code localement sans utiliser aucune sorte de contrôle de version. Avec la complexité croissante de ce site, cela devient de plus en plus irresponsable. Qu'est-ce qui a changé et quand? Pourquoi cela a-t-il changé? Comment pouvons-nous voir ce que c'était avant au cas où cela causerait des problèmes que nous ne découvrirons que plus tard?
Il y a tellement de bonnes raisons d'utiliser le contrôle de version que cela sort presque du cadre de cette série, mais il suffit de dire que nous allons l'utiliser. Cela résout toutes les questions que j'ai décrites ci-dessus.
Dans notre cas, j'utilise déjà le contrôle de version sur CSS-Tricks. J'utilise Git et j'héberge le référentiel sur Beanstalk. Beanstalk se charge de déployer le site via FTP. La configuration est méga simple. Pour CSS-Tricks, je n'ai même pas de serveur intermédiaire, je mets tout simplement en production.
J'utilise la tour de l'application Mac pour travailler avec Git. Si vous voulez un screencast complet sur la façon de tout configurer à partir de zéro, je l'ai disponible ici.
Nous faisons un petit changement et vous pouvez voir le changement apparaître dans Tower comme un «dif» (où vous pouvez voir quelle ligne a changé et comment). En fin de compte, nous prenons notre conception statique sur laquelle nous avons travaillé jusqu'à présent et en faisons un sous-dossier sur le vrai CSS-Tricks.com déployé - puis allons le regarder. Ouais ça marche! Bien, pour la majeure partie. Maintenant que la conception est dans un sous-dossier, certains des liens sont rompus, mais ce n'est pas grave.
Je dois noter que je ne reviens pas assez souvent pour me montrer des fichiers de commit sur Git dans de futures vidéos. Imaginez simplement qu'à la fin de chaque vidéo, je rebondis sur Tower, je sélectionne des groupes de fichiers pertinents et je les valide avec un joli message de validation descriptif (ce que j'ai fait).
