Git im Webdesign: Nicht nur was für Entwickler
Git – im Alltag vieler Webdesigner ein Fremdwort. Warum auch, solange alles läuft? Entwürfe kommen rein, CSS wird geflickt, der Kunde will „nur kurz“ was anders. Plötzlich stapeln sich Dateien: button_neu.css, hover_alt.css, final_v2_wirklich_final.css. Wer sucht, verliert. Welche Datei ist jetzt aktuell? Wo ist der Hover von letztem Dienstag abgeblieben? Und warum ist die letzte Version eigentlich schon wieder nicht final?
Git bringt da Ruhe rein. Jede Änderung landet sauber im Verlauf, alte Stände bleiben erreichbar, das Team sieht, was Sache ist. Keine Raketenwissenschaft, auch ohne Ninja-Kommandozeile. Einmal die Basics geschnallt, spart man sich viel Frust. Branches, Commits, Deployment – das reicht schon. Mehr braucht’s selten.
Branches: Spielwiese ohne Nebenwirkungen
Ein Branch ist so etwas wie eine eigene Baustelle. Einmal abgezweigt, kann hemmungslos experimentiert werden, ohne dass das Hauptprojekt in Schutt und Asche liegt. Klassiker:
- Beim Redesign einen neuen Branch ziehen
- Änderungen gefahrlos ausprobieren
- Nach Freigabe alles wieder zusammenschieben
Wenn sich das neue Farbkonzept als Augenschaden entpuppt – kein Drama. Die Hauptversion hat davon nichts mitbekommen. Zwischen den Zweigen wechseln? Ein Befehl, fertig. Wer so arbeitet, hat selten wieder Lust auf das Risiko, alles direkt auf die Live-Dateien zu knallen.
Commits: Speicherpunkte mit Klartext
Commits sind wie kleine Notizbücher. Nach jeder Änderung wird festgehalten, was passiert ist – und zwar mit Kommentar. Die Mini-Checkliste:
- Datei ändern
- „git add“ drauf
- „git commit -m 'Klartext'“ hinterher
Technik-Gedöns? Eigentlich nur Disziplin. Statt „fix bug“ lieber „Navigation mobile gefixt“ oder „Button-Farbe von Pink auf Blau“. Wer das macht, freut sich später beim Nachschauen. „Update“ als Commit? Nach drei Wochen weiß niemand mehr, was das heißen soll.
Deployment: Von lokal zum Server – aber wie?
Git selbst lädt nichts hoch. Nach dem Commit muss der Stand rüber auf den Server. Zwei Wege tauchen immer wieder auf:
- Klassisch: FTP/SFTP-Upload – der Dauerbrenner
- Automatisiert: Git Hook, CI/CD, was das Hosting eben hergibt
Die meisten Designer bleiben erstmal beim manuellen Hochladen. Lokal committen, hochladen, fertig. Wer Lust auf Komfort hat, schaut sich automatische Tools an. Aber: Erst spannend, wenn das Hosting mitspielt und regelmäßig größere Updates anstehen. Sonst mehr Aufwand als Nutzen.
Konkretes Beispiel: CSS-Update mit Git
- Mit „git init“ das Projektverzeichnis fit machen
- Branch „button-hover-effect“ anlegen
- CSS editieren
- „git add“ und „git commit -m 'Hover-Effekt für Buttons'“
- Auf „main“ zurückwechseln, Branch mergen
- Hochladen per FTP/SFTP
Das Chaos ist damit vorbei. Keine Ratespiele mehr, keine Datei-Historie aus der Steinzeit.
Grafische Tools: Git ohne Terminal
Kein Bock auf schwarze Bildschirme? Verständlich. Es gibt genug Programme mit Mausbedienung: GitHub Desktop, GitKraken, SourceTree. Branches, Commits, Diffs – alles klickbar. Viele Editoren (z.B. VS Code) können Git direkt, ein paar Buttons genügen. Für Designprojekte reicht das locker. Terminal bleibt Deko.
Tägliche Stolperfallen
- Commit-Nachrichten im Telegrammstil: „Update“. Nach vier Wochen komplett rätselhaft. Lieber konkret.
- Merge-Konflikte: Wenn zwei gleichzeitig an einer Datei basteln, kracht’s. Dann hilft nur: Konflikt im Editor auflösen, neu committen.
- Deployment direkt aus Git? Ohne Serverkenntnisse oft Glücksspiel. Erstmal beim klassischen Hochladen bleiben, Automatisierung erst, wenn’s wirklich passt.
Fazit
Git ist kein Hexenwerk. Wer die Grundfunktionen kennt, spart viel Nerven. Branches, Commits, klarer Ablauf – und das Datei-Chaos gehört der Vergangenheit an. Tools mit Oberfläche nehmen die Angst vor wilden Befehlen. Wer einmal damit arbeitet, sucht garantiert nie mehr nach „final_final_v3b.css“ im Projekt-Ordner.
bye
mo
Anhänge
Zuletzt bearbeitet: