AOit Linux Admin Blog

Ein kurzer Tipp zum Zurücknehmen von GIT Commits in der Vorweihnachtszeit:

$ git commit --amend

Mehr Infos hier: http://progit.org/book/de/ch2-8.html

Wenn man mit Git arbeitet möchte man irgendwann einmal Code von anderen importieren.
Zum Beispiel um ein Plugin in seine Cakephp Applikation zu importieren. Oder man hat selbst verschiedene Projekte und möchte bestimmten Code wiederverwenden. Bei uns haben wir zum Beispiel das Frontend für unsere Kunden und das Backend für die Administratoren komplett von einander getrennt. Aber z.B. der CSS Code ist in beiden Projekten nahezu gleich. Und auch bestimmte Plugins kommen in beiden vor. Es wäre ein fast unmöglicher Aufwand in beiden Projekten immer den identischen Code zu haben.

Daher haben wir ein Konzept gefunden wie man mit solchen Abhängigkeiten flexibel umgehen kann.

$ cd mein-projekt
$ git clone <url-anderes-projekt> mein-unterprojekt
$ git add mein-unterprojekt/

Wichtig ist hierbei das beim letzten Befehl auch ein / am Ende steht. Andernfalls versucht Git den eigenen viel komplexeren Submodul-Modus zu benutzen.

Jetzt hat man praktisch zwei verschachtelte Git Repositorys. Wenn man nun das Unterprojekt updaten will, geht man wie folgt vor:

$ cd mein-unterprojekt
$ git pull

Das funktioniert weil immer das näherliegende .git Verzeichnis benutzt wird. Ein weiterer großer Vorteil ist das wir das Unterprojekt an unsere Projektbedürfnisse anpassen können.

Ein kleiner Wermutstropfen tritt auf wenn ein anderes Projektmitglied den Code vom Hauptprojekt "cloned". Der Code vom Unterprojekt ist zwar enthalten, aber nicht die direkte Abhängigkeit zum Unterrepository. Das lässt sich aber relativ einfach lösen in dem man bei Änderungen dann einfach den Ordner löscht mit "rm -Rf mein-unterprojekt" und wie oben gezeigt wieder neu cloned. Daher packen wir in jedem von uns angelegten Unterprojekt auch eine Readme mit den nötigen URL Infos hinein.

Git (dezentrales Versionsmanagement) hat eine tolle Funktion um Verzeichnisse aus der Versionierung auszuklammern. Man trägt einfach Zentral in der .gitignore die Dateien ein die man nicht mit versionieren möchte. Für Cakephps tmp Verzeichniss sieht das dann z.B. so aus:

tmp/*
tmp/logs/*
tmp/sessions/*
tmp/tests/*
tmp/cache/*
!tmp/cache/empty
tmp/cache/models/*
!tmp/cache/models/empty
tmp/cache/persistent/*
!tmp/cache/persistent/empty
tmp/cache/views/*
!tmp/cache/views/empty

Die Einträge mit einem ! bedeuten das genaue Gegenteil (sprich diese Dateien werden wieder in die Versionierung aufgenommen). Da GIT keine (leeren) Ordner verwaltet braucht man diese leeren empty Dateien. Das Beispiel ist nicht vollständig, da man auch die Config Dateien unter Umständen auschließen möchte.

Wenn man anfängt in seinem GIT Repository git-tag zu verwenden möchte man evtl. das diese beim PUSH in das "Remote Repository" übernommen werden.

Das wird aber bei einem Standard push nicht gemacht, sondern man muss es extra angeben:

git push --tags

Häufig werden wir von Kunden (meistens Agenturen oder Webentwickler) gefragt was wir im Bereich Projektverwaltung empfehlen können.

Wir selbst nutzen Redmine und sind damit äußerst zu frieden. Gerade wenn man viele Projekte verwalten will und auch ein Code Repository mit verknüpfen will, ist es ideal geeignet.

Ein kurzer Auszug aus der Feature Liste:

• Multi-Projektverwaltung
• Flexible Rechteverwaltung
• Flexibles Ticketsystem
• Gantt Chart und Kalendar
• Dokumente und Dateimanagement
• Feeds & E-Mail Benachrichtigungen
• Ein Wiki pro Projekt
• Ein Forum pro Projekt
• Zeiterfassung
• Benutzerdefinierte Felder für Bugs, Zeiterfassung, Projekte und Benutzer
• SCM Integration (SVN, CVS, Git, Mercurial, Bazaar and Darcs)
• Ticket erstellung via E-Mail
• LDAP Support
• Benutzer können sich selbst registrieren
• Mehrsprachigkeit
• Verschiedene Datenbankanbindungen (MySQL, SQLite, etc.)

ABER:

Redmine ist in Ruby geschrieben und basiert auf dem Framework Ruby on Rails. Daher ist die Installation etwas aufwendiger/ungewohnter für PHP Programmierer.

Wir bieten aber hierbei gerne unsere käuflichen Dienste an ;-)

Alleine aus Sicherheitsgründen sollten Passwörter und andere Zugangsdaten nie im Versionssystem (git, subversion etc.) landen. Hierzu bieten die gängigen Systeme "Ignore" Funktionen an. Allerdings ist dieses meistens zu viel des guten. Denn man möchte eigentlich ja doch die Grundstruktur der Konfiguration mit im Versionssystem verwalten.

Unsere Lösung für dieses Problem sieht wie folgt aus:

• Umbennung der normalen Konfigurationsdatei (git mv config.php config.php_default)
• Passwörter und andere Zugangsdaten durch Bezeichner ersetzen (MYUSER, MYPASSWD)
• config.php ignorieren (Eintrag in .gitignore)

Jetzt kann jeder Entwickler sich seine Version auschecken und hat seine eigene Konfigurationsdatei zur Verfügung. Andere Entwickler sehen wenn sich die config.php_default ändert und können dementsprechend Ihre lokale Version anpassen.

Wenn wir jetzt einen Schritt weiter denken, haben wir nun ein sehr schöne deployment Möglichkeit. Hier ein kurzer vereinfachter Auszug aus unserem Deploymentskript:

#!/bin/bash
mysql_user = "dbnutzer1"
cp config.php_default config.php
sed -i "s/MYUSER/$mysql_user/g;" config.php