Tot nu toe hebben we lokaal codewijzigingen aangebracht zonder enige vorm van versiebeheer. Nu de complexiteit van deze site toeneemt, wordt dat steeds onverantwoordelijker. Wat is er veranderd en wanneer? Waarom is het veranderd? Hoe kunnen we zien wat het was voordat het problemen veroorzaakt waar we later pas achter komen?
Er zijn zoveel goede redenen om versiebeheer te gebruiken dat het bijna buiten het bereik van deze serie valt, maar het volstaat om te zeggen dat we het gaan gebruiken. Het lost alle vragen op die ik hierboven heb geschetst.
In ons geval gebruik ik al versiebeheer op CSS-Tricks. Ik gebruik Git en host de repository op Beanstalk. Beanstalk zorgt voor de implementatie van de site via FTP. De installatie is mega eenvoudig. Voor CSS-Tricks heb ik niet eens een staging-server, ik push alles gewoon naar productie.
Ik gebruik de Mac-app Tower om met Git te werken. Als je een volledige screencast wilt over hoe je dat allemaal helemaal opnieuw kunt instellen, heb ik dat hier beschikbaar.
We maken een kleine wijziging en je kunt de wijziging in Tower zien verschijnen als een "dif" (waar je kunt zien welke regel is gewijzigd en hoe). Uiteindelijk nemen we ons statische ontwerp waar we tot nu toe aan hebben gewerkt en maken er een submap van op de echt geïmplementeerde CSS-Tricks.com - ga er dan naar kijken. Ja, het werkt! Nou ja, voor het grootste deel. Nu het ontwerp in een submap staat, zijn sommige koppelingen verbroken, maar dat maakt niet uit.
Ik moet opmerken dat ik niet vaak genoeg terugkom om mezelf in toekomstige video's commit-bestanden naar Git te laten zien. Stel je voor dat ik aan het einde van elke video naar Tower stuiter, relevante groepen bestanden selecteer en ze vastlegt met een mooi beschrijvend vastleggingsbericht (wat ik eigenlijk deed).
