Hasta ahora, hemos realizado cambios de código localmente sin utilizar ningún tipo de control de versiones. Con el aumento de la complejidad de este sitio, eso se está volviendo cada vez más irresponsable. ¿Qué cambió y cuándo? ¿Por qué cambió? ¿Cómo podemos ver qué era antes en caso de que cause problemas que solo descubriremos más tarde?
Hay tantas buenas razones para usar el control de versiones que está casi fuera del alcance de esta serie, pero basta con decir que lo usaremos. Resuelve todas las preguntas que describí anteriormente.
En nuestro caso, ya estoy usando el control de versiones en CSS-Tricks. Utilizo Git y alojo el repositorio en Beanstalk. Beanstalk se encarga de implementar el sitio a través de FTP. La configuración es mega simple. En el caso de CSS-Tricks, ni siquiera tengo un servidor de ensayo, simplemente lo llevo todo a la producción.
Utilizo la aplicación de Mac Tower para trabajar con Git. Si quieres un screencast completo sobre cómo configurarlo todo desde cero, lo tengo disponible aquí.
Hacemos un pequeño cambio y puedes ver el cambio aparecer en Tower como un "dif" (donde puedes ver qué línea cambió y cómo). En última instancia, tomamos nuestro diseño estático en el que hemos estado trabajando hasta ahora y lo convertimos en una subcarpeta en el CSS-Tricks.com implementado real; luego, véalo. ¡Sí, funciona! Bueno, en su mayor parte. Ahora que el diseño está en una subcarpeta, algunos de los enlaces están rotos, pero eso no es gran cosa.
Debo señalar que no regreso con la frecuencia suficiente para mostrarme a mí mismo enviar archivos a Git en videos futuros. Solo imagina que al final de cada video reboto en Tower, selecciono grupos relevantes de archivos y los envío con un encantador mensaje de confirmación descriptivo (que es lo que hice).
