Indtil nu har vi foretaget kodeændringer lokalt uden at bruge nogen form for versionskontrol. Med kompleksiteten af dette site stigende, bliver det mere og mere uansvarligt. Hvad ændrede sig og hvornår? Hvorfor ændrede det sig? Hvordan kan vi se, hvad det var før, hvis det forårsager problemer, som vi først finder ud af senere?
Der er så mange gode grunde til at bruge versionskontrol, at det næsten er uden for rækkevidden for denne serie, men det er tilstrækkeligt at sige, vi skal bruge det. Det løser alle de spørgsmål, jeg har skitseret ovenfor.
I vores tilfælde bruger jeg allerede versionskontrol på CSS-Tricks. Jeg bruger Git og er vært for lageret på Beanstalk. Beanstalk tager sig af implementeringen af webstedet via FTP. Opsætningen er mega enkel. For CSS-tricks har jeg ikke engang en iscenesætter, jeg skubber bare alt lige til produktion.
Jeg bruger Mac-appen Tower til at arbejde med Git. Hvis du vil have en fuldskærmsudsendelse om, hvordan alt dette oprettes fra bunden, har jeg det tilgængeligt her.
Vi foretager en lille ændring, og du kan se ændringen dukke op i Tower som en “dif” (hvor du kan se, hvilken linje der er ændret, og hvordan). I sidste ende tager vi vores statiske design, vi har arbejdet med indtil videre, og gør det til en undermappe på den rigtige implementerede CSS-Tricks.com - så se på det. Ja det virker! Nå for det meste. Nu hvor designet er i en undermappe, er nogle af linkene brudt, men det er ikke så meget.
Jeg skal bemærke, at jeg ikke vender tilbage ofte nok til at vise mig forpligte filer til Git i fremtidige videoer. Forestil dig, at jeg i slutningen af hver video hopper over til Tower, vælger relevante grupper af filer og forpligter dem med en dejlig beskrivende commit-besked (hvilket jeg faktisk gjorde).
