Mittlerweile habe auch ich meine erste Website auf der Codebasis am Start. Ein paar weitere Module habe ich per git submodule vom Repository git://git.drupalcode.org/ nach installiert.

Und die erste Bewährungsprobe hat das Setup schon mit Bravour bestanden: Das Drupal-Update vor einer Woche und die Views-Sicherheitsaktualisierung zur gleichen Zeit waren in Bestzeit mit

# git pull
# drush updatedb

aktualisiert. Das geht noch schneller als mit einem reinen Drush-Workflow. Und als Website-Betreiber hat man die Gewissheit, dass die Module in der Konfiguration zusammenpassen und das Update schmerzfrei sein kann. Ein Dank für den Service an Freistil Consulting!

Ich installiere Drush üblicherweise ins Verzeichnis /usr/local/share/drush, was mit

# cd /usr/local/share
# git clone git://git.drupalcode.org/project/drush
# ln -sf ../share/drush/drush /usr/local/bin/drush
# cd drush
# git tag
...
6.x-4.0-rc1
6.x-4.0-rc3
7.x-1.0-rc2
...
# git checkout 6.x-4.0-rc3

geschieht. Der Befehl git tag zeigt die Drush-Releases an, mit git checkout 6.x-4.0-rc3 wird die gewünschte Release eingestellt (in einem lokalen Git-Repository sind ja alle Versionen und damit auch alle Releases des Projekts enthalten).

Nun kann mit git pull jederzeit das Repository aktualisiert und eine neuere Drush-Version eingestellt werden. Und sollte es mit dem Releasekandidat (rc) Probleme geben, dann schaltet man einfach mit git checkout 6.x-3.3 die aktuelle stabile Version aus.

Geht es einfacher? ;-)

Update: Bei dem hier beschriebenen Setup gehe ich davon aus, dass der Rechner (ein Server?) von mehreren Benutzern genutzt wird. Deshalb die Installation unter /usr/local. Nutzt nur ein Benutzer auf dem Rechner drush, dann kann das der Benutzer gern in seinem Heimatverzeichnis installieren.

Gestern war ich bei dem Git-Workshop in Hamburg mit Jochen Illich als Tutor, und organisiert von Comm-Press. Eine tolle Erfahrung und schöne Zeit. Im Kurs selbst habe ich nicht so viel Neues gehört (außer dem submodules Konzept), aber zwischendurch gab es jede Menge wertvoller Infos. Nun werde ich mit Vollgas am PartMaster-Git-Repository arbeiten (und das Repository von Subversion nach Git migrieren) und meine Drupal-Sites auf Git umstellen – mit einem Branch für Drupal und den Modul-Kanon sowie je einem Branch für jede Website. Klingt nach ein paar schönen Projekten :)

Gern wieder!

PS: Die Fotos sind von @karstenfrohwein: http://yfrog.com/mtutdxj und http://yfrog.com/jk28jjj

Nun habe ich aber viele Projekte in Subversion-Repos und kann die nicht einfach ersetzen, mal bietet Google kein Git an, mal braucht es noch ganz viel Motivation bei meinen Kollegen. Aber ein Anfang sollte gemacht werden. Und dabei half mir das “git-svn” Modul. Damit lässt sich sehr elegant mit Git (und lokalem Repository) gegen ein Subversion-Repo arbeiten.

Für meine IDE Eclipse gibt es auch ein eGit-Plugin, aber dieses kennt das “git-svn” nicht. Im Netz fand sich eine Beschreibung, wir man die Subversion-Projekte mit git-svn auschecken und in den Eclipse-Workspace integrieren kann. Die Lösung, die Plugins aus dem Workspace heraus zu kopieren und den Inhalt auszutauschen und so (lest es einfach), fand ich aber ziemlich fragil.

Und ich fand eine Verbesserung:

• Man legt den Workspace in Eclipse an und wechselt in einer Shell in das Workspace-Verzeichnis¹
• mit git svn clone checkt man das Projekt in den Workspace aus
• In Eclipse ruft man den Import-Wizard auf “Import > Existing project into workspace”
• Hier such man den Workspace als Quellverzeichnis aus und “importiert” das Plugin in den Workspace. Achtung: Den Knopf “Copy files” (oder so) nicht anklicken.
• Nun “Team > Share project …” aufrufen, Eclipse erkennt die vorhandene Git-Konfiguration und Klicken auf “Finish” reaktiviert die Git-Anbindung des Plugins.

Nun kann man weiter am Code arbeiten und lokal einchecken/commiten. Das Einchecken ins Subversion erfolgt dann weiterhin in der Shell mit git svn dcommit.

Insgesamt immer noch eine wackelige Behelfslösung und ich hoffe, dass eGit auf dem Wege zu Version 1.0 auch die native Unterstützung für spendiert bekommt.

Mein persönlich wichtigster Punkt in seinem Blogbeitrag ist der Fünfte: “Experiment with distributed revision control systems”. Das “experiment” geht mir zu langsam. Wenn ich an die Vorgehensweise bei der verteilten Drupal-Entwicklung denke (entwickle was, mach daraus einen Patch, schreib ein Issue auf d.o und hoffe, dass es jemand rechtzeitig wahrnimmt und ein anderer Patch Deinen eigenen Patch bis zum Commit nicht zerbrechen lässt) dann klint das ziemlich unzeitgemäß. Und ist wohl auch ein grund dafür, dass zahlreiche Teilprojekte (z.B. Open Atrium) die konkrete Entwicklung nach Github und vergleichbare Plattformen verschoben haben.

Ich verstehe schon, dass viele Entwickler erstmal in ihrem derzeitigen Workflow abgeholt werden müssen und das git und andere verteilte Version Control Systems eine ganz neue Denkweise erfordern¹. Aber der zukünftige Workflow sollte sein: Erzeuge einen Fork, ändere was und melde es dem Maintainer. Und wenn Dein Fork zwischenzeitlich zerbricht, dann hol Dir die Änderungen aus dem Master in den Fork, repariere … und weiter gehts.

So will ich das haben. Auch für Contrib.* Am besten Jetzt!*

—

¹ Und dass das project.module auch noch viel Liebe braucht, um mit Git und den Forks und Workflows umzugehen.