Git Schulung – 3 Dinge, die peinlich sind

Durch eine kleine Git Schulung und dieses hilfreiche Tutorial können peinliche Fehler einfach vermieden werden. Der Siegeszug von Git in der Entwickler-Szene ist überwältigend. Gerade bei Web Developern ist es ein echter Standard geworden und wird neben der Versionierung auch für Deployments genutzt. So können Änderungen schnell und effizient ausgerollt werden, ohne das man sich um Detail oder Tools kümmern muss. In diesem Artikel geht es nicht um den besseren Einsatz von Build Pipelines, sondern um 3 kleine Wissenslücken, die immer wieder großflächig in der Szene auftauchen.

Git Schulung – pull –rebase

Git Schulung tig Command Line Tool

Wenn man nicht alleine an einem Repository arbeitet, kommen in der Zwischenzeit Änderungen von Kollegen auf dem Remote Repository an. Git ist ein verteiltes Versionssystem. Das lokale Repository kann als autark und eigenständig betrachtet werden. Das ist ein wesentlicher Unterschied zu SVN, der auch in unserer Git Schulung deutlich hervorgehoben wird. Und hier kann man sich übrigens auch gegen unterschiedliche Remote Repositories verbinden. Holt man jetzt die Änderungen von einem Remote Repository in das eigene lokale werden diese mit dem Rest der Software zusammengeführt. Gab es lokal keine Änderungen zeigt einem „git status“ nach einem „git fetch“ mit dem Hinweis „fast forward“ an, dass man die Inhalte einfach holen kann. Bei einem „git pull“ wird übrigens automatisch ein „fetch“ ausgeführt. Wenn es aber auch im lokalen Repo Änderungen gibt, wird auf jeden Fall ein „merge“ durchgeführt. Und hier gibt es unterschiedliche Strategien. Die sind in in den beliebten Tools Sourcetree und PhpStorm unterschiedlich ausgelegt. In Sourcetree wird ein „rebase“ ausgeführt und in PhpStorm jedesmal ein zusätzlicher Commit für den Merge automatisch erzeugt. Und das ist meiner Meinung nach unschön und auch unnötig. Es macht das Log unübersichtlicher. Aber was passiert hier im Detail. Es sind Änderungen zu parallelen Zeitpunkten passiert. Das natürliche Verhalten von Git ist es diese zusammenzuführen und diesen neuen Stand als einen separaten Commit zu markieren. Bei einem Rebase werden die parallelen Änderungen aber zeitlich hintereinander gebracht. Die eigenen Änderungen werden auf alle anderen gesetzt. Rebase – die Basis wird vom Remote aus neu gebildet und dann die eigenen Änderungen oben drauf gesetzt. Das bedeutet allerdings auch, dass die Zeitstempel die Commits nicht mehr in chronologischer Reihenfolge aufgelistet werden. Das müssen sie aber auch nicht, weil die logische Reihenfolge entscheidend ist. Und das hat sich in den meisten Teams durchgesetzt. Daher ist es wichtig sich hier auf einen Standard zu einigen und den auch durchzusetzen. Noch wichtiger ist es überhaupt über diese Dinge und Abläufe bescheid zu wissen und das nicht stumpf Tools zu überlassen. Es ist eben auch wichtig mal einen Blick in ein Git Log zu werfen. Auf der Command Line kann man generell ein „git pull –ff-only“ ausführen. Klappt das nicht kann man ein „git pull –-rebase“ nutzen. Das kann man übrigens auch in seiner globalen Konfiguration einstellen.

Eine globale .gitignore – Git Tutorial

Es gibt Dateien, die möchte man nicht in ein Projekt laden. Dazu gehört u.a. der .idea Folder von PhpStorm mit den Project Settings. Hier gibt es allerdings noch weitere Pitfails, die in unserer Git Schulung erläutert werden. Nicht nur das hier eine große Sicherheitslücke entsteht, wenn man den Ordner mit ausrollt, Kollegen zerhaut das natürlich auch die jeweilige lokale Arbeitsumgebung. Das ganze kann dann auch nur mit weiteren Checkouts bereinigt werden. Das ist ärgerlich und auch extrem peinlich. Die Einstellung gehören aber auf keinen Fall in die .gitignore im Projekt. Dazu kommen ja dann auch häufig die .DS_Store Datei vom Mac, die jedesmal angelegt wird, wenn man ein Folder im Finder öffnet. Das gilt natürlich auch für andere IDEs und Betriebssysteme. Von daher ist es wichtig eine eigene globale .gitignore anzulegen. Hier habe ich bereits vor einigen Jahren ein Git Tutorial zu geschrieben. Einmal eingerichtet, spart man sich damit auch eine Menge Ärger. Ein entsprechendes PhPStorm Plugin zeigt auch die Settings von beiden Files gemeinsam an. Das hilft bei der Entwicklung und dem Debugging.

Git professionell einsetzen – .gitkeep ist einfach falsch

Natürlich gibt es im Internet kleine Zufälle. Und dann wird etwas einfach von ganz vielen Leuten falsch kopiert. Die Macher hinter Git wollten nie ein .gitkeep File einführen. Es gibt keinen einzigen Hinweis in der offiziellen Doku von Git. Aber jede Menge auf Stackoverflow. Und so hat es das File dann auch tatsächlich in einzelne offizielle Frameworks geschafft und dadurch so etwas, wie eine offizielle Bestätigung erfahren. Auf Git selbst gab es vor einigen Jahren einmal den Hinweis darauf, dass es nicht falsch aber auf keinen Fall so gedacht ist. Den technische Hintergrund möchte ich an dieser Stelle allerdings auch noch einmal erklären. Git versioniert keine leeren Ordner. Diese werden aber immer wieder für eine Applikation gebraucht. Sei es für ein Caching oder Folder für User Uploads oder einfach im Rahmen von Imports. Und damit die Ordner bei einem „git checkout“ oder „clone“ auch angelegt werden, wurden in der Vergangenheit .gitkeep Files hinzugefügt. Und jetzt kommt der Nachteil. Diese müssen dann global in einer .gitignore ausgeschlossen und die Folder ebenfalls angegeben werden. Es ist also nicht mehr klar, wo diese Informationen genau hinterlegt sind. Fügt man jetzt ein File in einem solchen Ordner hinzu und möchte, dass es versioniert wird, dann kann man sich auf eine nicht ganz so einfache Suche begeben. IDEs und Tools haben sich da natürlich schon auf die User-Bedürfnisse eingestellt und handeln hier intuitiv richtig. Das trägt dann zur stärkeren Abhängigkeit von Tools bei, weil auf der Command Line ein „git status“ mehr unversionierte Files anzeigt als das Tool. Damit wird sich dann auch gar nicht mehr mit dem Status auf dem Remoteserver befasst. Der ist dann einfach in einem unübersichtlichen Zustand – also Admin Sache nach dem Motto “keine Ahnung was da ist, bei mir hier lokal ist ja auch alles in Ordnung”. Freunde des Software- Entertainments: das ist zu wenig. Bitte schaut euch die Lösung im nächsten Abschnitt an.

gitignore statt gitkeep – Git Schulung HowTo

Feedback ist wichtig wenn man draus lernt Es ist sehr wichtig sich ein klares Bild vom Level der Teilnehmer zu machen und nicht sich selbst in die Lage des Teilnehmers zu versetzen. Abholen, Dialoge und mehr Theorie wurde gewünscht. Also das genau Gegenteil von dem was ich von Schulungen erwarte. Skliss und Code. Heute gibt es einen neuen Start mit Folien, Leitfaden und einem Hemd. @gfucyrusag #ncafun #ncaevent #nevercodealone #AD #developer #softwaredevelopment #softwareengineering #html5 #css3 #java #javascript #python #php #womenintech #womenwhocode #engineer #webdeveloper #webdesign #webdevelopment #hacking #linux #ubuntu #macbook #citt

Ein Beitrag geteilt von Webdeveloper Tagebuch (@nevercodealone) am Jul 11, 2018 um 11:24 PDT

Wer sich mit Git auseinandersetzt, merkt ziemlich schnell, dass es einfach und genial ist. Gerade das vermitteln wir auch in unserer Git Schulung. Genau aus diesem Grund nutzt man auch ein gitignore File in einem Ordner, der praktisch leer angelegt wird und keine weiteren Files versionieren soll. Hier werden einfach zwei Zeilen eingetragen.
*
!.gitignore

Alles wird ignoriert ausser der gitignore selbst. Und genau so einfach ist Git. Der Vorteil liegt auf der Hand. Es ist sehr einfach und man kann hier auch problemlos Ausnahmen hinzufügen. Dazu ist es eine ganz klare Zuständigkeit. Hier muß man sich nicht die Files zusammensuchen, die auf diesen Ordner und ggf. Dateien wirken.

Fazit zu Git-Stolperfallen

Coder dürfen nicht einfach nur User von Tools sein. Das macht uns abhängig und wir beschäftigen uns auch zu wenig mit den Hintergründen in einer Technologie. Wir brauchen einfach nicht für jeden Scheiß ein eigenes Tool. Und Git steht halt im Wort schon für Scheiß. Das hat der Erfinder Linus Torvald as himself nicht umsonst so genannt. Das bedeutet nicht, dass wir keine IDE, wie PhPStorm benutzen dürfen und alles von Hand schreiben müssen. Und natürlich sind Tools wie Sourcetree auch nützlich. Wir haben hier Templates für unsere Commit Messages und einfach ein starkes UI-Interface. Aber eines ist ja auch im Leben klar, Dinge die man nicht hat braucht man auch nicht. Beispielsweise Cherry-Picks. Und auch immer wieder der Versuch, Dinge in der Vergangenheit zu bereinigen. Dann gibt es irgendwann einen „git push –force“ und die Ansage jeder müsse sich jetzt „–hard“ gegen das Remote Repo resetten. Ich kenne ein Team, das wochenlang an einem Revert Commit rumgedoktert hat. Über Stunden wurden hier Bälle in Sourcetree verrückt. Das lag aber auch an der völlig unmöglichen Art mit nur einem Preview und einem Develop Branch zu arbeiten. Aber man hielt sich ja streng an Git-Flow, weil man immer einen Release Branch nur für den Merge in Develop erstellt hat. Local für sich selbst wohlgemerkt. Hier sollte man auch einfach mal den Kopf aus dem Sand nehmen und mal mit 2-3 hellen Momenten den Rest des Jahres einfach viel bessere Arbeitsbedingungen und vor allem Spaß in ein Projekt bringen.

Git Schulung für Git Tricks und Git-Flow

Wir haben mit der Entwicklungshilfe NRW eine Git-Schulung mit praktischen Beispielen erstellt, in der wir mit einigen wenigen Beispielen in einem halben Arbeitstag fundiertes und nachhaltiges Wissen in Teams bringen, ohne dabei über bestehende Workflows zu richten. Alle Infos gibt es hier.

Wir freuen uns gerne über Feedback. Schreibt doch einfach was ihr von dem Artikel haltet hier drunter oder über unsere Social Media Kanäle. Hier lohnt sich auch ein Folgen.