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.

Voraussetzungen für einen erfolgreichen Workflow

Grundlage für den hier gezeigten Workflow sind PhpStorm als IDE mit installiertem git-flow-Plugin sowie ein funktionierendes Ticketsystem Redmine. Natürlich gibt es Alternativen zu dieser Kombination. PhpStorm arbeitet mit sehr vielen Systemen zusammen, und auch andere IDEs haben ähnliche Funktionen. Der Workflow im Versionskontrollsystem basiert auf unserer git-flow-Präsentation und ist aus meiner Sicht zwar im Feinen anpassbar, im Groben aber alternativlos.

Ticketsystem Redmine richtig einstellen

Das Ticketsystem sollte von außen erreichbar sein. Der zur Verknüpfung benutzte User sollte im Ticketsystem aktiv sein und Projekte und Tasks – im Weiteren auch Issues genannt – zugewiesen haben. Zusätzlich muss die REST-Api in der Konfiguration des Ticketsystems aktiviert sein.

In PhpStorm geht es weiter

In PhpStorm geht man zunächst über die Tastenkombi cmd+“,“ (Mac) in die Einstellungen und navigiert zu Tools -> Tasks -> Servers. Dort setzt man nach Auswahl des Ticketsystems die URL und Zugangsdaten zu seinem Ticketsystem.

Ein Klick auf den Test-Button liefert das Ergebnis:

Im zweiten Reiter stellt man die Commit-Einstellungen ein. Das Ticketsystem Redmine ist in der Lage, Commit-Nachrichten auszulesen und darauf zu reagieren. Eine sinnvolle Einstellung zur Automatisierung spart hier wertvolle Zeit.

Optimaler Workflow in PhpStorm mit dem Ticketsystem Redmine

Die Voraussetzungen sind hier ein Projekt im ausgecheckten develop-Branch, ein vorhandenes Ticket und eine eingerichtete Entwicklungsumgebung.

Die Steuerungsleiste für das Taskmanagement befindet sich im rechten oberen Bereich.

Über das Dropdown kommt man in den „Task öffnen“-Dialog.

Nach erfolgreichem Öffnen eines Tasks sollte man eine für den Task eingerichtete Changelist in PhpStorm und auf Ebene der Versionskontrolle einen Feature-Branch ausgecheckt haben.

Sollte man seine relevanten Entwicklungen lokal abgeschlossen haben, kommt der Zeitpunkt, an dem man seinen Code committet. Durch die Nutzung der taskrelevanten Changelisten ist dies selbst bei Bearbeitung mehrerer Issues in einem Projekt durchschaubar. Zudem verringern die voreingestellten Informationen aus dem Ticketsystem die manuell einzugebenden Informationen.

Vor dem anschließenden Push zeigt PhpStorm eine Zusammenfassung der Änderungen.

Als Abschluss muss man das Feature leider noch manuell über das git-flow-Plugin schließen, aber ich hoffe, dass das in naher Zukunft automatisiert wird.

Als Meldung sollte PhpStorm einblenden, dass der Feature-Branch erfolgreich zurückgemerged wurde.

Es kann zudem vorkommen, dass PhpStorm die Changelist nicht löscht. Um die Ordnung nicht zu verlieren, hilft das manuelle Löschen.

Außerdem kann es helfen, bei zu vielen Issues in der Liste auch diese manuell zu löschen.

Überprüfung in der Versionskontrolle und im Ticketsystem Redmine

Wer ähnlich wie wir Redmine mit gitolite und dem redmine git hosting nutzt, kann jetzt in seinem Projekt bei Redmine im Projektarchiv seinen neuen Workflow überprüfen.

Weiterführende Informationen zum Beispiel vom PhpStorm-Hersteller Jetbrains bekommt ihr hier.

Nutzt ihr in euren PHP-Projekten eine andere Kombination von Ticketsystem, Versionskontrolle und IDE? Wenn ja, dann schreibt uns hier doch bitte mal, welche das sind. Denn von einem solchen Know-how-Austausch profitieren ja letztlich alle. Die oben beschriebene Kombination schulen wir übrigens auch.

Der Beitrag PhpStorm mit dem Ticketsystem Redmine nutzen 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.

„WordPress ohne FTP updaten (oder installieren)“ ist eine vielgenutzte Phrase bei der Google-Suche – kein anderes bekanntes CMS-System nutzt diese Art für die Installation und die Aktualisierungen bei Plugins. Insofern ist es immer wichtig, im Vorfeld Sicherheitsmaßnahmen zu definieren und dann vor allem auch umzusetzen. Regelmäßige Updates sind ebenfalls von zentraler Bedeutung für die Sicherheit in Open-Source-Anwendungen. Das WordPress-Backend macht zuverlässig und übersichtlich auf Aktualisierungen aufmerksam.

Plugins: WordPress ohne FTP updaten

Damit die Installationen von WordPress ohne FTP (File Transfer Protocol) vorgenommen werden können, ist es nötig, ein Setting in der wp-config.php hinzuzufügen.

define('FS_METHOD', 'direct');

Mit dem oben abgebildeten Setting ist es möglich, als eingeloggter User alle Aktualisierungen von WordPress im Backend vorzunehmen. Nach den Aktualisierungen kann man die Zeile dann wieder auskommentieren. Generell sind Updates nur durchzuführen, wenn man vorher ein vollständiges Backup erstellt hat. Zu dem Thema habe ich bereits einen Gastbeitrag in einem Online-Fachmagazin veröffentlicht.
http://www.zielbar.de/blogger-erfolgreich-wordpress-einsetzen-4251/

FTP und die Frage der Sicherheit

Das FTP wird gerade bei einfachen Hosting-Lösungen häufig eingesetzt. In dem Artikel FTP: Die unterschätzte Sicherheitslücke findet man eine Auflistung möglicher Schwachstellen. (WordPress-)Updates ohne FTP sind nur eine davon. Grundsätzlich gibt es in puncto Sicherheit keinen 100-prozentigen Schutz, und außerdem gilt noch immer der Leitsatz: „Statistische Sicherheit: Ein System wird dann als sicher bezeichnet, wenn für den Angreifer der Aufwand für das Eindringen in das System höher ist als der daraus resultierende Nutzen. Deshalb ist es wichtig, die Hürden für einen erfolgreichen Einbruch möglichst hoch zu setzen und damit das Risiko zu reduzieren„. Denn ist der Aufwand für den Angreifer zu hoch, so lässt er schnell ab. Näheres dazu (und mehr Wissenswertes zum Thema) findet man in dem Wikipedia-Eintrag zu Informationssicherheit.

Daher hat WordPress FTP als Sicherheitsbarriere eingebaut. So kann auch ein Administrator keine Plugins installieren oder aktualisieren, ohne einen FTP-Zugang zu haben. Das gibt es in anderen CMS-Systemen wie TYPO3 nicht. Professionelle Hosting-Lösungen arbeiten mit einem SSH-Zugriff. In Kombination mit einem SSH Key hat man die Zugriffe sehr gut unter Kontrolle und kann sie gegebenenfalls sofort wieder entfernen. Zudem wird auch protokolliert, wer die Änderungen durchgeführt hat. Bei FTP-Zugängen von Webhosting-Paketen gibt es in der Regel nur einen Zugang, den dann mehrere Personen nutzen. Änderungen bedeuten also zusätzlichen Kommunikationsaufwand.

WordPress Hosting Backups

Auch der Verlust eines privaten Hobby-Blogs ist sehr schmerzhaft. Man muss aber kein Sicherheitsexperte werden, damit man einen Blog erfolgreich und sicher betreiben kann. Wichtig ist aber in jedem Fall ein zuverlässiges Backup, damit man jederzeit den Stand von gestern oder vorgestern wiederherstellen kann. Das beseitigt zwar nicht das Sicherheitsloch an sich, aber es begrenzt schon mal erheblich den entstandenen Schaden. Denn so geht dann maximal die Arbeit von 24 oder 48 Stunden verloren – das ist zwar immer noch ziemlich ärgerlich, aber letztlich noch überschaubar. Achtet bei euren Hosting-Anbietern also genau auf die Backup-Strategie! Wichtig sind Frequenz, Menge und Ausmaß. Hingegen nur die Datenbank zu sichern, reicht nicht aus.

Entwicklungshilfe bei WordPress-Blogs

Fragen zum Thema WordPress & Hosting beantworten wir gerne und leisten auch tatkräftig Unterstützung. Nehmt dazu einfach Kontakt mit uns auf.

Der Beitrag Plugins: WordPress ohne FTP updaten erschien zuerst auf Entwicklungshilfe NRW.