Git branch delete merged – Aufräumen der lokalen Umgebung

Von Roland Golla
0 Kommentar
Git branch delete merged

Beim lokalen Git Repository sucht man schnell nach „Git branch delete merged“. Gerade lokal sammeln sich schnell viele Git Branches an. Arbeitet man nach Git Flow, oder legt einfach für jedes Ticket einen weiteren lokalen Branch an, dann sind hier nach einigen Wochen wirklich viele zusammengekommen. Wechselt man hier mit oh-my-zsh und einer Tab-Autocompletion auf einen Branch, dann wird es hier sehr unübersichtlich. Also muss einfach mal aufgeräumt werden. Ein erster Schritt ist es hier alle Git Branches die bereits gemerged sind zu löschen.

List merged Git branches – Liste alle Branches die in den aktuellen Branch gemerged wurden

Git branch delete merged - Git Schulung für PHP Entwickler
Git branch delete merged – Git Schulung für PHP Entwickler
git branch --merged

Mit diesem Linux Command werden alle Branches aufgeführt, die bereits in den aktuellen Branch gemerged wurden. Achtung bei dem kleinen Pitfail, hier unbedingt darauf achten, daß man sich auch auf dem wahrscheinlich gewünschten master Branch befindet. Sonst kann das Ergebnis falsch sein. Hier fällt aber auch gleich auf, dass man Git Branches, wie dev, develop oder stage gerne behalten möchte. Dafür kann man einfach mit einem egrep (exclude grep) arbeiten.

Exclude develop Branch on git branch –merged

git branch --merged| egrep -v "(^\*|master|dev|develop|stage)"

Das hier ist ein wichtiger Schritt. Ansonsten verschwinden die Standard Git Braches, die man so für die Entwicklung braucht. Persönlich bin ich allerdings beim Never Code Alone Flow dazu übergegangen einen aktuellen Master-Branch als Staging Umgebung zur Verfügung zu stellen. Dabei wird jeder Branch als Feature Wildcard als Preview Ansicht zur Verfügung gestellt. sowas wie https://feature123.develoop.nevercodealone.de. Die Features werden immer in der GitLab Pipeline mit statischer Code Analyse und allen Codeception Acceptance Tests gechecked. Bei erfolgreicher manueller Abnahme erfolgt dann der Merge. so kann man dann auch einfach den Merge wieder rückgängig machen. Das macht die Entwicklung etwas besser. Die Pipeline gibt es hier im Video.

Delete all merged git branches – Alle Git Branches die gemerged sind löschen

git branch --merged | egrep -v "(^\*|master|dev)" | xargs git branch -d

Und dann wird es ernst. Aber natürlich schützt uns Git hier auch weiterhin vor unüberlegten Handlungen. In diesem Fall sogar doppelt. Einmal kommen Git Branches, die nicht zu 100% gemerged sind nicht in die List. Das kann passieren, wenn man Beispielsweise einen Bug auf dem bestehenden Git Branch und Ticket fixt, ohne extra einen Bugfix Branch zu eröffnen. Die Git Branch delete Funktion bricht allerdings auch ab, wenn ein Änderung noch nicht gemerged ist. In diesem Falle sind wir also doppelt gesichert. Dafür sogt hier das kleine „-d“. Ein großes „-D“ ist so ein Force Delete.

Git Branches remote Repositories

Aufräumen kann man natürlich auch ein remote Git Repository. Das ist allerdings mit Vorsicht zu tun, da es sich ja hier um die echte „Wahrheit“ handelt. Sinnvoller ist es hier über GitLab mit einer Pipeline zu arbeiten und Branches die erfolgreich gemerged wurden automatisch zu löschen. In der Regel kann man mit seinem eigenen User auch keine remote Git Branches löschen. Für den fall der Fälle würde ich mich allerdings auch mit dem Terminal mit dem Git Server verbinden und die Schritte hier, wie auch lokal ausführen.

Zur CI Pipeline in 3 Tagen – Softwarequalität in einer praktischen 2 + 2 Schulung

Continuous Integration Schulung
Continuous Integration Schulung

Automaisierte Deployments und Tests bieten einen Wettbewerbsvorteil. Ohne die wird es auch schwer weiter zu bestehen. Die enormen Kosten wird kein kunde mehr tragen. Und das sogenannte „Schmerzensgeld“, wenn es denn bei den Entwicklern überhaupt ankommt, gleicht nicht den Frust und die fehlende Leidenschaft aus. Von daher muss einfach mal was passieren. Wir haben hier eine passende Schulung für PHP-Projekte entwickelt und bringen euch in 3 tagen zur eigenen Build Pipeline. 2 Tage arbeite ich mit den Entwicklern an der Erstellung unterschiedlicher Testverfahren. Also statische Code Analyse mit PHPStand und natürlich Codeception PHPUnit und Acceptance Tests. An den anderen Tagen gibt es dann von Andreas Mautz eine DevOp oder Admin Schulung. Er übernimmt die neuen Tests aus der Schulung und baut damit eine CI Pipeline auf. Sprecht uns einfach an. Hier geht es zu weiteren PHP Schulungen.

0 Kommentar

Tutorials und Top Posts

Gib uns Feedback

Diese Seite benutzt Cookies. Ein Akzeptieren hilft uns die Seite zu verbessern. Ok Mehr dazu