In Stellenausschreibungen steht heute immer öfter die Anforderung, Git über die Command Line zu nutzen. Gerade bei Senior-Entwicklern wird dieses Wissen bereits explizit vorausgesetzt. Das Command-Line-Wissen kannst du dann auch anwenden, wenn dir kein Rechner mit Sourcetree zur Verfügung steht, weil du dich vielleicht direkt auf den Linux-Servern lokal oder remote bewegen musst.

Git Commands, die tatsächlich gebraucht werden

Es sind nicht so viele Git Commands, die für die tägliche Arbeit gebraucht werden, wie man vielleicht glaubt. Hier mal ein einfacher Task mit den Git-Commands direkt auf der Command Line.

Git Repository klonen

git clone https://url.com/example-repo

Mit dem Git Command wird das Repo in das Verzeichnis „example-repo“ geklont. Gibt man hinter der URL ein anderes Ziel oder Target an, wird ein anderer Ordner genommen. Das macht bei der späteren Anwendung keinen Unterschied, kann aber zu mehr Übersicht in der Dateistruktur genutzt werden. Mit der Angabe von „.“ wird das Repository in das aktuelle Verzeichnis geklont. Das ist zwar ein seltener Anwendungsfall, spart einem aber bei Bedarf Zeit. Dafür muss der Ordner allerdings vollständig leer sein. Auch die Verzeichnisse der PHP-IDEs, wie PhpStorm, dürfen hier nicht vorhanden sein.

Branch erstellen

git checkout -b myNewTask
Mit dem Checkout-Befehl und dem Parameter -b wird ein neuer Branch „myNewTask“ erstellt und automatisch auf diesen gewechselt. Hier ist darauf zu achten, auf welchen Branch man sich zu dem Zeitpunkt der Erstellung befindet, und natürlich auch darauf, dass man den aktuellsten Stand auscheckt – also vorher ein „git pull“ ausgeführt hat.

Developing auf dem Branch

git add . && git commit -m “#myNewBranch add css file”
oder
git add layout/mynewtask.css && git commit -m “#myNewBranch add css file”

Generell soll ja bei jeder funktionierenden Änderung ein Commit gemacht werden. Hier ist Disziplin gefragt. Grafische Tools wie Sourcetree verleiten jedoch dazu, dies zu einem späteren Zeitpunkt zu machen. Hier kann man sehr einfach einzelne geänderte Zeilen separaten Commits zuweisen. Das bedeutet leider noch lange nicht, dass der Commit tatsächlich alles tut, was er soll, und wie gewünscht funktioniert hat.

Insofern ist es besser, regelmäßig kleine Commits zu machen. Der Git-Add-Befehl dient dabei einmal für das separate File und einmal für alles seit dem letzten Commit. Auch hier gilt: Regelmäßige und sinnvolle Commits machen einem das Leben leichter und sind effektiver. Vorher ist es zudem immer sinnvoll, sich die aktuellen Änderungen mit „git status“ noch einmal anzeigen zu lassen. Denn schließlich kommt es vor, dass man etwas übersehen hat. Das trifft auch auf von der Applikation generierte Files zu, die eventuell noch über .gitignore ausgeschlossen werden müssen.

Commit Messages

Damit man die Historie einer Entwicklung nachvollziehen kann, sind Commit Messages wichtig. Diese müssen aussagekräftig sein und beinhalten idealerweise eine Ticket-ID. Denn somit können die Arbeitsschritte direkt zugeordnet werden. Nicht aussagekräftige Commit Messages indes schaden dem Team und einem selbst.

Mit Pre Hooks ist es möglich, Commits ohne Ticket-ID direkt zu unterbinden. Das kann sogar erweitert werden, dass sich das Ticket im richtigen Status befinden muss. Solche Maßnahmen einzuführen und umzusetzen, ist allerdings nicht so einfach wie deren technische Implementierung.

Es gibt einige Spaßseiten zu dem Thema wie beispielsweise Commits from last night – dabei ist das Thema doch eigentlich sehr ernst. Denn es dient der Dokumentation der eigenen Arbeit und zeigt, dass du ein Profi bist. Soll heißen: Arbeite immer möglichst professionell. Das ist wichtig und richtig.

Git-flow installieren und sofort nutzen

git flow feature start myNewBranch
git flow feature finish myNewBranch

Git-flow hat sich in vielen Projekten bewährt und wird vor allem gerne bei neuen Projekten eingesetzt. Auf dem Mac ist es schnell mit Homebrew installiert, und nach einem „git flow init“ kann es nach einigen Bestätigungen der Default-Settings sofort eingesetzt werden. Mit dem oben aufgeführten Start-Befehl wird dabei ein neuer Branch aus dem aktuellen Develop Branch erstellt. Danach kann man sein Feature entwickeln und mit dem Finish-Befehl wieder abschließen. Hier wird ein Merge zurück in den Develop Branch ausgeführt und der Feature Branch sofort gelöscht. Falls man das aber nicht unbedingt möchte, geht es auch mit Hotfixes und Releases.

Eine gute Übersicht zu all dem bietet http://danielkummer.github.io/git-flow-cheatsheet/. Ausführliche Informationen zu Git-flow gibt es außerdem unter https://github.com/nvie/gitflow. Wir haben uns im praktischen Einsatz dazu entschlossen, nach dem Git-Flow-Workflow zu arbeiten, die zusammengeführten Branches allerdings zu archivieren und zu erhalten.

Git-Workflow nur auf der Command Line

Der Git-flow ist eine Zusammenfassung von Befehlen, die man selbstverständlich auch eigenhändig und einzeln ausführen kann. In meinen Augen ist aber ein großer Nachteil, dass Branches, die zurückgemerged wurden, auch gelöscht werden.

Persönlich finde ich es zudem besser, Bugfixes auf dem Feature Branch durchzuführen und sich öfter mit dem aktuellen Stand abzugleichen. So kann man die Arbeit auf einem Feature besser dokumentieren. Das Ganze geht manuell auf der Command Line – CLI – wie folgt:

// Aktuellen Develop Branch auschecken und aktualisieren
git checkout develop
git pull

// Feature Branch für Jira Ticket SUP-123 erstellen
git checkout -b feature/SUP-123

// Commits auf das Ticket
git status
git add . && git commit -m “#SUP-123 what i have done”

// Git Pushes sollten mindestens jeden Abend durchgeführt werden – und zwar auf jeden Fall vor den Merges, egal in welche Richtung
git status
git push

// Feature Branch zurück in Develop bringen
git checkout develop
git pull
git merge feature/SUP-123
git status

// Tag setzen
git tag -a v1.2.0 -m “Version v1.2.0”
// Push mit Tags
git push && git push –tags

Die oben aufgeführten Commands in oh-my-zsh
// Aktuellen Develop Branch auschecken und aktualisieren
gco develop
gl

// Feature Branch für Jira Ticket SUP-123 erstellen
gcb feature/SUP-123

// Commits auf das Ticket
gst
gaa && gcmsg “#SUP-123 was ich gerade getan habe”
gst

// Git Push sollte mindestens jeden Abend durchgeführt werden – und zwar auf jeden Fall vor den Merges, egal in welche Richtung
gst
gp

// Feature Branch zurück in Develop bringen
gco develop
gl
gm feature/SUP-123
gst

// Tag setzen
git tag -a v1.2.0 -m “Version v1.2.0”

// Push mit Tags
gp && gp –tags

Mit oh-my-zsh sind eine Vielzahl von Git Commands als Alias abgelegt. Im praktischen Einsatz kommen in meinen Augen die oben abgebildeten zum Tragen. Allein gaa && gcmsg „my message“ bringen einem sehr viel, da sie ein häufiger Anwendungsfall sind. Auch gc für git checkout geht schnell in Fleisch und Blut über.

Probleme mit Git

Git-Konflikte sind ein großes Thema bei Git und natürlich auch Themen wie Rebase. Aber in diesem Artikel gehe ich nicht zusätzlich auf diese Themen ein. In Zukunft werden wir hier in unserem Webdevelopment-Blog das Thema Git auch in anderen Zusammenhängen aufgreifen. Auch gehe ich nicht auf Tools, wie Tig ein. Aber natürlich ist es wichtig und richtig, mit visuellen Tools zu arbeiten.

Fazit zu Git auf der Command Line CLI

Git ist in der heutigen Zeit des Webdevelopments der Quasi-Standard. Jeder Entwickler, egal ob Frontend oder Backend, muss damit umgehen können. Man braucht und darf keine Ausreden bei der Nutzung einer Command Line haben. Nur so wird man zum Profi – sonst ist man nur ein Anwender. Ein User.

In diesem Artikel ist ein einfaches Beispiel über die Entwicklung eines Feature Branches abgebildet. Man sieht ganz deutlich, dass nur wenige Commands nötig sind. Es ist wichtig, diese einfachen Vorgänge zu 100 Prozent auf der Command Line durchführen zu können und dies auch regelmäßig zu tun. Nur so lernt man Git richtig.

Unsere Git-PHP-Schulung

Git wird von vielen Webdevelopern benutzt. Sie haben es aber leider häufig nicht verinnerlicht oder verstanden, warum man damit genau so arbeitet, wie man es tut. In unserer Schulung gehen wir ganz praktisch vor und erklären Git von den Grundlagen bis zu praktischen und etablierten Workflows. Wir gehen auf die Anwendungsfehler ein und geben unsere persönliche Erfahrung direkt an die Teilnehmer weiter. Es ist eine sehr individuelle Intensiv-Schulung. Alle Informationen zu dem Thema gibt es auf
http://www.entwicklungshilfe.nrw/seminare/git-flow-git-branching-model-fuer-agile-software-projekte/

Wie nutzt du Git bislang? Hast du es schon mal per Command Line versucht, und wie sind da ggf. deine Erfahrungswerte?

Der Beitrag Git auf der Command Line CLI einsetzen erschien zuerst auf Entwicklungshilfe NRW.

Änderungen wie “Git ignore file mode” gehören dazu, da man diese Git-Einstellung nicht in jedem Projekt neu setzen muss. Es gibt mehrere Anwendungsfälle, die wir auch in unseren Git-Schulungen vorstellen werden. Es ist sinnvoll, die Einstellung global vorzunehmen – den Befehl sollte man aber dennoch auswendig kennen, falls man mal auf einem anderen System unterwegs ist.

Git ignore file mode global setzen

git config --global core.filemode false

Die oben abgebildete Zeile setzt durch den –global-Parameter die Einstellung global für den eingeloggten User. Das ist sehr praktisch, da die Einstellung in allen Projekten benötigt wird.

Git ignore file mode lokal setzen

git -c core.filemode=false diff

Neben der globalen Konfiguration ist es in Git natürlich auch möglich, die Einstellung nur für das aktuelle Projekt vorzunehmen. Der oben abgebildete CLI-Befehl setzt die Konfiguration nur für das aktuelle Projekt Verzeichnis.

Git filemode

Es kommt vor, dass durch Benutzerrechte Änderungen im lokalen Workspace entstehen und Git diese Änderungen als Change erkennt und committen möchte. Das ist zwar technisch richtig, häufig jedoch unerwünscht. Hierfür kann man ein Setting in der Git-Konfiguration setzen. Das lässt sich lokal oder global machen. Dessen sollte man sich immer bewusst sein und wissen, dass in Zukunft eventuell berechtigte Änderungen an den Zugriffsrechten nicht wirksam werden, wenn man das Setting global gesetzt hat. Für Änderungen in diesem seltenen Fall sollte man das Repo noch einmal explizit auschecken und die gewünschten Änderungen dort vornehmen und in das Remote Repository bringen. So spart man sich das lästige Hin- und Herkonfigurieren.

Weiterführende PHP-Schulung zum Thema Git

Wenn ihr euch gezielt zum Thema Git weiterbilden und viele praktische Tipps für eure Arbeit erhalten möchtet, könnte euch unsere entsprechende PHP-Schulung interessieren. Infos dazu findet ihr hier. Insgesamt zielen die Seminare und Workshops von Entwicklungshilfe NRW – ebenso wie unser Blog – darauf ab, Webentwicklern die Arbeit zu erleichtern und dadurch für mehr Spaß und Motivation zu sorgen. Wenn ihr euch übrigens gerade fragt, wie ihr eure Vorgesetzten vom Nutzen einer Weiterbildung überzeugen könnt, dann hilft euch vielleicht dieser Beitrag hier weiter.

Falls ihr noch Fragen zum Thema Git ignore file mode habt, dann könnt ihr diese gerne in den Kommentaren stellen. Wir werden euch so schnell wie möglich antworten.

Der Beitrag Git ignore file mode global oder lokal setzen? erschien zuerst auf Entwicklungshilfe NRW.

Redmine 3 mit Gitolite 3 installieren

Eine gelungene, kostenfreie Kombination für ein Ticketsystem mit Versionskontrolle bieten Redmine als Ticketsystem und git als Versionskontrolle. Gitolite dient dabei als Mittler, um Nutzer des Ticketsystems gegenüber dem eigenen Git-Server zu authentifizieren und so die Versionskontrolle über das Ticketsystem steuerbar zu machen. Mehr dazu gibt es im neuen Jahr in einem eigenen Blog-Beitrag, den ich dann hier verlinke.

Voraussetzungen für die neue Infrastruktur

Dieser Artikel ist eine Anleitung, wie man auf einem eigenen, dafür geeigneten Server diese Kombination aufsetzt.
Ausgegangen wird hier von Debian als Betriebssystem, und der eingeloggte User ist root. Es wird vorausgesetzt, dass man Pakete installieren und einen einfachen Editor wie vim oder nano benutzen kann.

Zunächst installiert man die grundlegenden Softwarepakete, die benötigt werden:

apt-get install rubygems gitolite3 build-essential libssh2-1 libssh2-1-dev cmake libgpg-error-dev mysql apoache2

Anschließend werden dem System zwei User für git („git“) und Redmine („redmine“) hinzugefügt:

adduser --system --shell /bin/bash --gecos 'Git Administrator' --group --disabled-password --home /opt/gitolite git
adduser --system --shell /bin/bash --gecos 'Redmine Administrator' --group --disabled-password --home /opt/redmine redmine

Da das Ticketsystem später die Kontrolle über die Versionskontrolle ausüben soll, legen wir einen SSH-Key für den User redmine an:

su redmine
ssh-keygen -t rsa -N '' -f ~/.ssh/redmine_gitolite_admin_id_rsa
exit

Versionskontrolle kontrollieren

Nun kann Gitolite mit

dpkg-reconfigure gitolite3

neu konfiguriert werden, da die Konfiguration bei Installation ein paar Settings anders setzt, als wir es gerne hätten. Die Parameter zur Konfiguration sind:
user: git
repos path: /opt/gitolite
admin ssh-key: /opt/redmine/.ssh/redmine_gitolite_admin_id_rsa.pub

Redmine und Gitolite benötigen teilweise sudo-Rechte für den jeweilig anderen User, Redmine für die Installation temporär sogar darüber hinaus. Dazu konfigurieren wir unseren Server für das Ticketsystem mit Versionskontrolle mit

visudo

Folgendes wird zusätzlich eingetragen:

# temp – *REMOVE* after installation
redmine ALL=(ALL) NOPASSWD:ALL

# redmine gitolite integration
redmine ALL=(git) NOPASSWD:ALL
git ALL=(redmine) NOPASSWD:ALL

Installation des Ticketsystems Redmine

Jetzt wird Redmine installiert. Dazu loggen wir uns als User redmine ein und wechseln in sein Home-Verzeichnis.

sudo su - redmine
cd ~

Wir befinden uns jetzt in /opt/redmine, wo wir den aktuellen Code über github ziehen.

git init
git remote add origin https://github.com/redmine/redmine.git
git fetch -p

Da wir uns im Home-Verzeichnis befinden, schließen wir noch ein paar Verzeichnisse und Dateien aus:

vim .gitignore

Auszuschließende Items sind zum Beispiel:
.ssh/
.bash_history

Als nächstes checken wir die aktuelle stabile Version aus.

git add .gitignore
git commit -m 'local gitignore'
git checkout 3.1-stable

An dieser Stelle kann man jetzt noch die Quelle vom Original zu einer eigenen Quelle verschieben.

git remote rm origin
git remote add origin __URL__

Wir benutzen Redmine mit einer MySQL-Datenbank. Sollte noch kein MySQL-Server installiert sein, bitte nachholen. Ansonsten mit

mysql -u root -p -v -e "CREATE DATABASE redmine CHARACTER SET utf8; CREATE USER '__USER__'@'localhost' IDENTIFIED BY '__PASSWORD__'; GRANT ALL PRIVILEGES ON redmine.* TO '__USER__'@'localhost';"

__*__ bitte mit geeigneten Werten ersetzen.

Das oben erstellte Login verwenden wir nun zur Konfiguration von Redmine. Wir kopieren die Config-Templates und editieren diese:

cd /opt/redmine/config
cp database.yml.example database.yml
cp configuration.yml.example configuration.yml

vim database.yml
vim configuration.yml

Erweiterte Erläuterungen zur Konfiguration gibt es hier für die Datenbank und hier für Generelles.

Danach wechseln wir zurück ins Home-Verzeichnis und beginnen mit der Installation. Zur eigentlichen Installation von Redmine müssen wir im Gemfile noch eine Anpassung vornehmen.

cd ~
sudo gem install bundler
nano Gemfile

Hier ändern wir die mysql2-Version auf 4.2.0, wenn man Percona als MySQL-Server in der Version 5.6 benutzen möchte.

Jetzt wird endlich installiert:

bundle install --without development test postgresql sqlite
rake generate_secret_token
RAILS_ENV=production rake db:migrate

Plugins für das Ticketsystem

Nachdem Redmine grundlegend installiert wurde, kümmern wir uns jetzt um die Plugins:

cd ~/plugins
git clone https://github.com/jbox-web/redmine_bootstrap_kit.git
git clone https://github.com/jbox-web/redmine_git_hosting.git
cd redmine_bootstrap_kit/
git checkout 0.2.4
cd ../redmine_git_hosting/
git checkout 1.2.0
cd ~
bundle install --without development test
bundle exec rake redmine:plugins:migrate RAILS_ENV=production NAME=redmine_git_hosting

Der eingangs erstellte SSH-Key wird jetzt in das Plugin verlinkt:

ln -s /opt/redmine/.ssh/redmine_gitolite_admin_id_rsa /opt/redmine/plugins/redmine_git_hosting/ssh_keys/redmine_gitolite_admin_id_rsa
ln -s /opt/redmine/.ssh/redmine_gitolite_admin_id_rsa.pub /opt/redmine/plugins/redmine_git_hosting/ssh_keys/redmine_gitolite_admin_id_rsa.pub

Das Ticketsystem mit Versionskontrolle überprüfen

Wir wechseln jetzt auf die Seite des Users git und überprüfen Gitolite.

sudo su - git
sed -i 's/$GL_GITCONFIG_KEYS = ""/$GL_GITCONFIG_KEYS = ".*"/g' /opt/gitolite/.gitolite.rc
exit
ssh -i .ssh/redmine_gitolite_admin_id_rsa git@localhost info

Dabei sollte eine Antwort ähnlich wie diese hier kommen:
hello admin, this is git@__SERVER__ running gitolite3 3.6.1-2 (Debian) on git 2.1.4

R W gitolite-admin
R W testing

Als letztes wird nun Redmine mittels des Passenger-Moduls zum Laufen gebracht. Es wird vorausgesetzt, dass ein entsprechender vhost-Eintrag existiert, der auf /opt/redmine/public verweist. Das Passenger-Modul installiert man mit

passenger-install-apache2-module

und trägt danach die in der Installation erzeugten Pfade in die apache-Konfiguration ein.

Bei mir hat diese Anleitung zum Aufsetzen eines Ticketsystems mit Versionskontrolle bisher immer sehr gut funktioniert. Wenn ihr Probleme habt, schreibt bitte in die Kommentare, damit diese Anleitung ständig verbessert werden kann. Gleichzeitig können wir durch den regen Ausstausch mit euch aber auch die Qualität unserer PHP-Schulungen für Webentwickler noch weiter erhöhen.

Quellen und weiterführende Links:
Redmine
Gitolite
Redmine und Gitolite
Apache Passenger
Redmine git hosting
Redmine git hosting Plugin-Seite

Der Beitrag Ticketsystem mit Versionskontrolle erschien zuerst auf Entwicklungshilfe NRW.