Auf der Suche nach einer Möglichkeit, besser im Team an Webprojekten zu arbeiten, entdeckten wir letztes Jahr das Versionskontrollsystem Git. Nach anfänglichen Schwierigkeiten, ist es mittlerweile zu einem unersetzlichen Bestandteil unseres Workflows für größere Projekte geworden.
Das letzte Jahr war ein Jahr mit vielen Neuerungen für uns. Angefangen mit der Entwicklung einer internen Zeiterfassung mittels Contao, dem Entschluss Websites künftig nur noch in HTML5 zu entwickeln, bis hin zur Einführung von Git gab es eine Menge zu lernen. Ein paar mit Git realisierte Projekte später will ich euch einen kleinen Einblick geben, wie wir mit Git im Team an Webprojekten arbeiten.
Das Problem: Zeitgleich an Dateien arbeiten
Frei übersetzt von der offiziellen Git Website ist Git ein freies, dezentralisiertes Open Source Versionskontrollsystem. Es ist für kleine wie große Projekte geeignet und überzeugt durch Geschwindigkeit und Effizienz.
Bevor wir Git einsetzten sah unser Workflow eher so aus: Das CMS (meist Contao) wurde auf einem Testserver installiert und alle Projektteilnehmer arbeiteten direkt auf dem Server. Ab und zu wurde ein Backup erstellt, um den Totalcrash zu verhindern. Wenn mehrere Teammitglieder an der Umsetzung eines Screendesigns arbeiteten (was bei großen Projekten recht häufig vorkommt), wurde mündlich oder per Nachricht mitgeteilt, dass entsprechende Template-Dateien, vor allem CSS-Dateien zur Zeit in Bearbeitung sind, damit Kollegen sich nicht gegenseitig die Dateistände überschrieben. Klar, dass es dennoch immer wieder zu Problemen kam. Was wir suchten, war eine Lösung, um mit mehreren gleichzeitig an einer Datei arbeiten zu können.
Die Lösung: lokale Entwicklungsumgebungen mittels Git synchronisieren
Es klingt zunächst ein wenig umständlich. Warum sollte jeder Nutzer eine lokale Kopie des Webprojektes auf der Festplatte haben? Die Antwort liegt in der Arbeitsweise von Git selbst. Da es sich bei Git um ein dezentrales System handelt, werden alle Änderungen am Projekt zunächst lokal protokolliert und mit den Änderungen der anderen Teammitglieder abgeglichen bevor sie zusammengeführt werden. So ist (normalerweise) sichergestellt, dass das auf dem Server liegende Git Repository weiterhin funktionstüchtig und konfliktfrei bleibt.
Für die Umsetzung eines Screendesigns bedeutet das, das mehrere Leute zeitgleich an beispielsweise einer CSS-Datei arbeiten können. Durch das Speichern und Hochladen (Pushen) auf den Git-Server wird die Dateiänderung auch den anderen Teammitgliedern zur Verfügung gestellt. Wenn Diese sich den letzten Stand der CSS-Datei runterladen, können die eigenen Änderungen und die des anderen Teammitglieds automatisch zusammengeführt (gemerged) werden. Im Konfliktfall, also wenn z.B. 2 Nutzer in der gleichen Zeile etwas geändert haben, kann der Nutzer mit der letzten Änderung entscheiden, ob er lieber seine Änderung oder die Änderung des anderen Teilnehmers speichern möchte. Auch nachträgliches Umentscheiden ist dank der Versionierung super einfach.
Wir nutzen zur Verwaltung von lokalen Git Repositories das kostenlose Programm Source Tree, da wir es mit dem Terminal nicht unbedingt so haben. Lediglich bei der Fehlermeldung, beispielsweise beim Mergen, kommen ich regelmäßig ins Schwitzen. Es hat eine Weile gedauert, bis ich verstand, dass von Source Tree gesetzte Kommentare in zusammengeführten Dateien noch angepasst werden müssen, um den Code wieder funktionstüchtig zu machen.
Bisher ungelöste Probleme bei der Verwendung von Git
Bisher nutzen wir Git nur sehr rudimentär. Um die Entwicklung übersichtlich zu halten, arbeiten wir ausschließlich im Master-Branch, wir haben also nur ein Projektstrang, in dem alle Ihre Änderungen vornehmen. Zwar wäre es denkbar, für Teilbereiche der Website auch eigene Branches anzulegen (z.B. HEADER, FOOTER, NAV), man merkt jedoch sehr schnell, dass Git und auch der offizielle Git Flow mit Features, Bugfixes, Develop- und Production-Branch eher davon ausgeht, dass man ein bestehendes System hat, an dem immer wieder neue Funktionen ergänzt werden oder Bugs behoben werden müssen. Für den Aufbau eines Webprojektes von null an, eignet sich der Git Flow nicht ganz so gut.
Auch endet unser Git-Workflow bisher nach Launch eines Projektes, da durch den Umzug auf den Live-Server der Abgleich mit dem Git-Server wegfällt (bei den meisten Kunden, haben wir nur ein kleines Hostingpaket zur Verfügung) . Hinzu kommt, dass viele Content Management Systeme ja nicht nur Datei- sondern auch datenbankbasiert arbeiten. Das macht es schwer, auf einer Entwicklungsumgebung weiterzuentwickeln, während der Kunde in der Live-Umgebung neue Inhalte einfügt und Dateien einfügt oder löscht. Auch die Erstellung von neuen Modulen oder Seitenlayouts läuft bei vielen CMS datenbankbasiert. Einfach blind alle Entwicklungen auf dem Live-Server einzuspielen könnte gefährlich werden.
Wünschenswert wäre außerdem, eine gewisse Form der Versionierung für die MySQL-Datenbank zu haben. Hier behelfen wir uns momentan mit manuellen Backups und Erweiterungen wie FullBackup für Contao. Doch hilft uns das nur, um regelmäßig Backups zu machen. Es müssen momentan alle Entwickler auf die gleiche, eine Remote-Datenbank zugreifen, um den aktuellsten Stand des Systems zu haben.
Fazit: Für große Projekte ist Git unverzichtbar
Heute möchte ich bei keinem großen Projekt mehr auf Git verzichten. Gerade wenn man bedenkt, auf welch dünnem Eis wir uns bewegt haben, als wir nur alle paar Wochen mal ein Backup von dem letzten Projektstand gemacht haben.
In Zukunft möchte ich Git auch vermehrt bei kleineren Projekten einsetzen. Zu häufig habe ich in den letzten Monaten erlebt, dass wir uns gegenseitig CSS-Anweisungen überschrieben. Mit Git lässt sich dieser Umstand zwar nicht unbedingt abstellen, aber die Versionierung macht es einfacher, zum vorherigen Schritt zurückzukehren und die Commits geben gute Aufschlüsse darüber, wer was und wofür gemacht hat.
Wenn ihr schon länger überlegt, euch Git mal anzuschauen, dann macht es. Es lohnt sich auf jeden Fall, auch wenn die Einrichtung etwas langwieriger ist. Wenn ihr dafür noch einen fähigen Hoster sucht, empfehle ich euch uberspace.de. Möglichkeiten und Support sind meiner Meinung nach zur Zeit unschlagbar.
Hallo Dennis,
ich finde es immer wieder spannend Erfahrungsberichte von anderen mit GIT zu lesen und gerade auch an stellen, die bei der Entwicklung von GIT gar nicht gedacht wurde.
GIT wurde ja damals von Linus Torwals zu besseren Verwaltung des Linux Kernels ins Leben gerufen, nach sein vorher verwendes System Properitär wurde.
Also im Prinzip, wie von dir beschrieben, ein bestehendes großes System, welches einfach nur weiterentwickelt wurde.
Zudem handelte es sich fast ausschließlich um reinen C-Code.
Vor 2 Jahren habe ich GIT bei uns in der Firma (Agentur) eingeführt. Zuerst an einem großen bestehenden System und später nach den ersten Erfahrungen habe ich Schulungen für meine Kollegen gegeben, die nun GIT für ihre alten, aber auch neuen Projekte nutzen. Darunter CMS Systeme, Hybris, Magento, aber auch Eigenentwicklungen. Alles im Bereich von eCommerce und Brand Communications.
Meine Erfahrungen nach über 2 Jahren sind gemischt. Zwar bin ich von GIT weiterhin überzeugt. Jedoch sehe ich auch immer wieder den Widerstand bei uns in der Firma und das teilwese widerwillig nutzen von GIT.
Meist ist der Widerstand darin begründet, dass GIT nicht richtig verstanden wurde und/oder falsch genutzt wird. Denn auch dies ist leicht möglich.
Immer wieder kommt es auch zu Mergekonflikten, die eigentlich keine Konflikte sind. Den Grund habe ich auch nach 2 Jahren noch nicht komplett herausbekommen.
Man muss dazu sagen, dass wir GIT bei uns mit über 20 Enwicklern und über 3 Agenturen hinweg nutzen, um an einem gemeinsamen Projekt zu arbeiten.
Oftmals liegen Konflikte darin begründet, dass Entwickler Code refaktorisieren, Klassen verschieben, Formatierungen ändern (Zeilen einrücken oder verschieben) oder durch unterschiedlichen Entwicklungsumgebungen und Betriebsystemübergreifend andere Lineendings (CRLF/CR/LF) in den Projektdateien verwenden, die dann als Änderunge der gesamten Datei angesehen werden.
Oftmals sind die Konflikte aber auch nicht erkennbar und das schafft dann Unmut.
Nichts desto trotz ist nach einer Eingewöhnungsphase und nach dem Erkennen aller Vorteile der Großteil der Entwickler der Meinung, dass es gut war von SVN zu GIT zu wechseln.
Zwar mag das Arbeiten zuerst etwas schwieriger erscheinen, aber die Vorteile sind immens.
Ich kann dir nur zustimmen, ausprobieren lohnt sich!
Auch wenn dein Artikel ein wenig älter ist, rein vom Inhalt ist er noch immer aktuell.
Zu diesem Absatz hier ein Kommentar von mir:
„Auch endet unser Git-Workflow bisher nach Launch eines Projektes, da durch den Umzug auf den Live-Server der Abgleich mit dem Git-Server wegfällt (bei den meisten Kunden, haben wir nur ein kleines Hostingpaket zur Verfügung) .“
Es gibt Deploymenttools, die einen beliebigen Branch via SSH oder FTP auf den Kunden hochladen können. Das funktioniert also auch bei einem normalen Hostingpaket. ;-)
Das Problem mit dem „Versionieren“ von Datenbanken haben alle CMS Systeme, egal ob Typo3, Contao, WebEdition usw. … da machen dann „eigene“ Projekte mit Frameworks Sinn, die die Datenbank komplett über ORM abbilden (Doctrine & Co).