Hittills har vi gjort kodändringar lokalt utan att använda någon form av versionskontroll. Med den här webbplatsens komplexitet ökar blir det mer och mer oansvarigt. Vad förändrades och när? Varför förändrades det? Hur kan vi se vad det var tidigare om det orsakar problem som vi först får reda på senare?
Det finns så många bra anledningar att använda versionskontroll att det nästan inte omfattas av serien, men det räcker att säga att vi ska använda den. Det löser alla frågor som jag skisserat ovan.
I vårt fall använder jag redan versionskontroll på CSS-Tricks. Jag använder Git och är värd förvaret på Beanstalk. Beanstalk tar hand om att distribuera webbplatsen via FTP. Installationen är mega enkel. För CSS-Tricks har jag inte ens en iscensättningsserver, jag skjuter bara allt rätt till produktion.
Jag använder Mac-appen Tower för att arbeta med Git. Om du vill ha en helskärmssändning om hur du ställer in allt från grunden har jag det tillgängligt här.
Vi gör en liten förändring och du kan se förändringen dyka upp i Tower som en “dif” (där du kan se vilken linje som ändrats och hur). I slutändan tar vi vår statiska design som vi hittills har arbetat med och gör den till en undermapp på den riktiga distribuerade CSS-Tricks.com - se sedan på den. Ja det fungerar! Tja, för det mesta. Nu när designen finns i en undermapp är några av länkarna trasiga men det är ingen stor sak.
Jag bör notera att jag inte återvänder tillräckligt ofta för att visa mig engagera filer till Git i framtida videor. Föreställ dig att i slutet av varje video hoppar jag över till Tower, väljer relevanta grupper av filer och gör dem med ett härligt beskrivande engagemangsmeddelande (vilket är vad jag faktiskt gjorde).
