Agile Softwareentwicklung - Nützliche Tricks für den Git-Alltag

In den Beiträgen Agile Softwareentwicklung - Software im Team entwickeln hatte ich mich mit den allgemeinen Begriffen (Contributor, Maintainer, Pull Request / Merge Request, Commit und Issue) beschäft und GitHub Flow kurz erklärt.

In der c't 17/2025 gibt es einen guten Beitrag zum Thema "Git-Stolperfallen im Alltag". Siehe https://www.heise.de/select/ct/2025/17/2519512434440349082.

Dabei werden folgende nützliche Tricks für den Git-Alltag gegeben:

• Wie kann ich verhindern, dass sensible Daten versehentlich in einem Commit landen?
• Stelle sicher, dass Dateien mit sensiblen Informationen (z.B. .env, config.json) in der .gitignore Datei aufgeführt sind.
  
• Wie finde ich heraus, welche Code-Zeile von welchem User kommt?
• git blame <dateiname>
• Für detaillierte Historie:
• git log -L :functionName:<dateiname>
• Für eine bestimmte Zeilenrange:
• git log -L 10,20:<dateiname>
  
• Wie behebe ich einen missratenen Commit vor dem Push? Ich vergesse häufig Dateien oder vertippe mich in der Commit-Nachricht. 
• git commit --amend
  
• In einem Projekt pflegen wir zahlreiche Branches und verlieren häufig den Überblick. Was können wir besser machen? 
• Ein konsistentes Namensschema hilft sofort beim Erkennen des Zwecks eines Branches
• feature/<ticket-id>-<beschreibung>
• bugfix/<ticket-id>-<beschreibung>
• hotfix/<beschreibung>
• release/<version>
  
• Ich habe ein Projekt gestartet, an dem nun weitere Leute mitwirken sollen. Wie sollten die Commits idealerweise aussehen, damit das Projekt wartbar bleibt?
•  Ein guter Commit sollte kurz, präzise und aussagekräftig sein. Ideal ist ein zweigeteilter Aufbau:
• Kurze Zusammenfassung (max. 50 Zeichen)
• Optional: ausführlichere Beschreibung (max. 72 Zeichen/Zeile)
• Ich habe zahlreiche unterschiedliche Änderungen an einer Datei vorgenommen, wie reiche ich diese in mehreren Commits ein? 
• Datei nicht direkt committen, sondern Änderungen stagen
• git add -p <dateiname>
  
• Ein Git-Repository soll auf einen anderen Server verschoben werden. Wie geht das am einfachsten? 
• Repository klonen und auf neuen Server pushen
• git clone --bare <url-zum-alten-repo>
• cd <repo-name>.git
• git remote add new-origin <url-zum-neuen-repo>
• git push --mirror new-origin

 

Agile Softwareentwicklung - Software im Team entwickeln (Glossar)

In dem Beitrag "Agile Softwareentwicklung - GitHub Flow notwendig?" habe ich den "GitHub Flow" kurz erklärt. Etwas näher möchte ich auf die allgemeinen Begriffe (Contributor, Maintainer, Pull Request / Merge Request, Commit und Issue) in der Softwareentwicklung im Team eingehen.

Contributor

Wenn jemand als Entwickler etwas zu einem Projekt beiträgt, der darf sich offiziell Contributor (Mitwirkender) nennen. Dies trifft auch dann zu, wenn man nur einen kleinen Tippfehler in der Dokumentation beseitigt, was für viele der Einstieg in ein Open Source-Projekte ist. Da die meisten Softwareprojekte in Regel bei GitHub oder GitLab verwaltet werden, kann man mit einem eigenen Account dort sofort mit der Unterstützung beginnen.

Maintainer

Nicht jeder, kann aber sofort Änderungen am Quellcode oder der Dokumentation vornehmen. Jedes Entwicklungsprojekt benötigt einen oder mehrere Maintainer (Betreuer). Sie haben die Berechtigung, eingereichte Änderungen zu akzeptieren und in den Quellcode aufzunehmen. Zudem kümmern Sie sich um geplanten Funktionen für neue Versionen und legen fest wohin sich das Projekt entwickelt soll.

Pull Request / Merge Request

Möchte man Änderungen an einer Software vornehmen, muss mann zunächst einen neuen "Fork" (Verzweigung) anlegen. Dies ist eine lokale Kopie der aktuellen Code Basis. Jetzt kann man all seine geplanten Änderungen vornehmen. Anschließend kann man einen Request mit seinen Änderungen an das Originalprojekt stellen. Bei GitHub und Bitbucket heißen diese Request "Pull Request" und GitLab nennt sie "Merge Request". Der Maintainer prüft nun die Änderungen und entscheidet, ob sie für eine Übernahme geeignet sind.

Commit

Hinweis: Die Befehle "git commit" und "svn commit" haben denselben Namen, sie unterscheiden sich aber voneinander! Siehe auch https://www.atlassian.com/de/git/tutorials/saving-changes/git-commit.

Hat man seine Änderungen fertiggestellt (z.B. die Programmierung eines neuen Moduls), erzeugt man einen Commit. Dadurch werden die Änderungen als Entwicklungsschritt in die Quellcode-Chronik mit aufgenommen und mit einer kurze Nachricht versehen. Hierdurch sehen auch die anderen Entwickler diese in ihrer Chronik.

Online Visitenkarte mit GitHub Pages

Mit Hilfe von GitHub Pages ist es relativ schnell möglich eine online Visitenkarte oder auch einen Blog vollkommen kostenlos zu erstellen.

Alles was hierzu nötig ist, ist ein GitHub Account (in der kostenlosen Version):

 
Jetzt muss man ein Repository erstellen (z.B. mit dem Namen "card"):

Anschließend kann man das noch "leere" Repository aufrufen:

Jetzt kann man direkt eine neue Datei mit dem Namen "index.md" anlegen (https://github.com/shemel/card/new/master) und dort seine Informationen (Visitenkarte etc.) hinterlegen:

Hierbei handelt es sich dann um ein Markdown (vereinfachte Auszeichnungssprache): https://github.com/shemel/card/blob/master/index.md

Unter den Einstellungen (Settings) des Repository kann man unter dem Punkt "GitHub Pages" verschiedene Themes aussuchen:

Hier sollte man jetzt den "master branch" und ein passendes "Theme" auswählen. Das Theme selber wird in der "_config.yml" abgelegt:

Jetzt ist die Visitenkarte unter der folgenden URL abrufbar: https://shemel.github.io/card/