Do tej pory wprowadzaliśmy zmiany w kodzie lokalnie bez korzystania z jakiejkolwiek kontroli wersji. Wraz ze wzrostem złożoności tej witryny staje się to coraz bardziej nieodpowiedzialne. Co się zmieniło i kiedy? Dlaczego to się zmieniło? Jak możemy zobaczyć, co to było wcześniej, na wypadek gdyby powodowało problemy, o których dowiemy się dopiero później?
Jest tak wiele dobrych powodów, by używać kontroli wersji, że jest to prawie poza zakresem tej serii, ale wystarczy powiedzieć, że będziemy z niej korzystać. Rozwiązuje wszystkie pytania, które nakreśliłem powyżej.
W naszym przypadku używam już kontroli wersji w CSS-Tricks. Używam Gita i hostuję repozytorium na Beanstalk. Beanstalk zajmuje się wdrażaniem witryny za pośrednictwem protokołu FTP. Konfiguracja jest mega prosta. W przypadku sztuczek CSS nie mam nawet serwera przejściowego, po prostu wysyłam wszystko prosto do produkcji.
Do pracy z Git używam aplikacji Mac Tower. Jeśli chcesz zobaczyć pełny ekran pokazujący, jak to wszystko skonfigurować od zera, mam to tutaj.
Dokonujemy niewielkiej zmiany i możesz zobaczyć zmianę w Tower jako „dif” (gdzie możesz zobaczyć, która linia się zmieniła i jak). Ostatecznie bierzemy nasz statyczny projekt, nad którym do tej pory pracowaliśmy, i robimy z niego podfolder w prawdziwym wdrożonym CSS-Tricks.com - a następnie spójrz na to. Tak, to działa! Cóż, w większości. Teraz, gdy projekt znajduje się w podfolderze, niektóre łącza są uszkodzone, ale to nic wielkiego.
Powinienem zauważyć, że nie wracam wystarczająco często, aby pokazać swoje pliki do Git w przyszłych filmach. Wyobraź sobie, że pod koniec każdego filmu przeskakuję do Tower, wybieram odpowiednie grupy plików i zatwierdzam je za pomocą uroczego, opisowego komunikatu o zatwierdzeniu (co faktycznie zrobiłem).
