Bisher haben wir Codeänderungen lokal vorgenommen, ohne jegliche Versionskontrolle zu verwenden. Mit der zunehmenden Komplexität dieser Website wird dies immer unverantwortlicher. Was wurde wann geändert? Warum wurde es geändert? Wie können wir sehen, wie es vorher war, falls es Probleme verursacht, die wir erst später feststellen?
Es gibt so viele gute Gründe für die Verwendung von Versionskontrolle, dass es fast den Rahmen dieser Serie sprengen würde, aber wir werden sie auf jeden Fall verwenden. Sie löst alle von mir oben genannten Fragen.
In unserem Fall verwende ich bereits Versionskontrolle auf CSS-Tricks. Ich benutze Git und hoste das Repository auf Beanstalk. Beanstalk kümmert sich um die Bereitstellung der Website über FTP. Die Einrichtung ist super einfach. Für CSS-Tricks habe ich nicht einmal einen Staging-Server, ich pushe alles direkt in die Produktion.
Ich benutze die Mac-App Tower, um mit Git zu arbeiten. Wenn Sie eine vollständige Screencast-Anleitung wünschen, wie Sie das alles von Grund auf einrichten, habe ich diese hier verfügbar.
Wir nehmen eine kleine Änderung vor und Sie sehen die Änderung in Tower als "Dif" (wo Sie sehen können, welche Zeile sich geändert hat und wie). Letztendlich nehmen wir unser statisches Design, an dem wir bisher gearbeitet haben, und machen es zu einem Unterordner auf dem tatsächlich bereitgestellten CSS-Tricks.com – dann schauen wir es uns an. Yay, es funktioniert! Naja, größtenteils. Da das Design jetzt in einem Unterordner liegt, sind einige Links kaputt, aber das ist keine große Sache.
Ich sollte erwähnen, dass ich nicht oft genug zurückkehre, um mich selbst beim Committen von Dateien in Git in zukünftigen Videos zu zeigen. Stellen Sie sich einfach vor, dass ich am Ende jedes Videos zu Tower wechsle, relevante Dateigruppen auswähle und sie mit einer schön beschreibenden Commit-Nachricht committe (was ich tatsächlich getan habe).