Bis jetzt haben wir Codeänderungen lokal vorgenommen, ohne irgendeine Versionskontrolle zu verwenden. Mit der zunehmenden Komplexität dieser Website wird dies immer verantwortungsloser. Was hat sich wann geändert? Warum hat sich das geändert? Wie können wir sehen, was es vorher war, falls es Probleme verursacht, von denen wir erst später erfahren?
Es gibt so viele gute Gründe, die Versionskontrolle zu verwenden, dass sie fast außerhalb des Anwendungsbereichs dieser Serie liegt. Es reicht jedoch zu sagen, dass wir sie verwenden werden. Es löst alle Fragen, die ich oben skizziert habe.
In unserem Fall verwende ich bereits die Versionskontrolle für CSS-Tricks. Ich benutze Git und hoste das Repository auf Beanstalk. Beanstalk kümmert sich um die Bereitstellung der Site über FTP. Das Setup ist mega einfach. Für CSS-Tricks habe ich nicht einmal einen Staging-Server. Ich schiebe einfach alles richtig in die Produktion.
Ich benutze die Mac App Tower, um mit Git zu arbeiten. Wenn Sie einen vollständigen Screencast darüber wünschen, wie Sie alles von Grund auf neu einrichten können, finden Sie diesen hier.
Wir nehmen eine kleine Änderung vor und Sie können sehen, dass die Änderung im Tower als „Unterschied“ angezeigt wird (wo Sie sehen können, welche Linie 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 - und schauen es uns dann an. Ja, es funktioniert! Zum größten Teil. Jetzt, da sich das Design in einem Unterordner befindet, sind einige der Links defekt, aber das ist keine große Sache.
Ich sollte beachten, dass ich nicht oft genug zurückkehre, um mir in zukünftigen Videos Commit-Dateien für Git zu zeigen. Stellen Sie sich vor, dass ich am Ende jedes Videos, das ich zu Tower überspringe, relevante Gruppen von Dateien auswähle und sie mit einer schönen beschreibenden Commit-Nachricht festschreibe (was ich tatsächlich getan habe).
