Até agora, temos feito alterações no código localmente, sem usar qualquer tipo de controle de versão. Com o aumento da complexidade deste site, ele está se tornando cada vez mais irresponsável. O que mudou e quando? Por que mudou? Como podemos ver o que era antes, caso cause problemas que só descobriremos mais tarde?
Existem tantos bons motivos para usar o controle de versão que está quase fora do escopo desta série, mas basta dizer que vamos usá-lo. Ele resolve todas as questões que descrevi acima.
No nosso caso, já estou usando o controle de versão no CSS-Tricks. Eu uso o Git e hospedo o repositório no Beanstalk. Beanstalk se encarrega de implantar o site através de FTP. A configuração é mega simples. Para CSS-Tricks, eu nem tenho um servidor de teste, apenas envio tudo para a produção.
Eu uso o app Tower do Mac para trabalhar com o Git. Se você quiser um screencast completo sobre como configurar tudo do zero, tenho-o disponível aqui.
Fazemos uma pequena mudança e você pode ver a mudança aparecer na Torre como um “dif” (onde você pode ver qual linha mudou e como). Por fim, pegamos nosso design estático no qual estivemos trabalhando até agora e o tornamos uma subpasta no CSS-Tricks.com real implantado - então, dê uma olhada nele. Oba, funciona! Bem, para a maioria. Agora que o design está em uma subpasta, alguns dos links estão quebrados, mas isso não é grande coisa.
Devo observar que não volto com frequência suficiente para me mostrar submetendo arquivos ao Git em vídeos futuros. Imagine que no final de cada vídeo eu pulo para a Torre, seleciono grupos de arquivos relevantes e os envia com uma mensagem de commit descritiva adorável (que é o que eu realmente fiz).
