Git

Git hilft in vielfältiger Art und Weise bei der Organisation von Code aber auch bei Automatisierung von Deployments.

Hier ein paar hilfreiche Grundlagen zur Arbeit mit Git, hier am beispiel Github.

1. Repository erstellen

Der einfachste Weg ein neues Repository zu erstellen ist dieses direkt auf Github anzulegen und erst danach lokal zu klonen.

Also einfach auf github.com unter dem eigenen Account ein neues Repository anlegen.

Achte beim anlegen darauf, dass der Hauptbranch „main“ und nicht „master“ benannt wird.

Das Repository kann anschließend lokal geklont werden:

git clone https://github.com/<dein-username>/git_workflow.git 
cd git_workflow

git clone https://github.com/<dein-username>/git_workflow.git 
cd git_workflow

2. Python Projekt erstellen

Erstelle eine einfache Python Datei mit Namen „app.py“:

def add(a, b):
    return a + b

if __name__ == "__main__":
    print(add(2, 3))

def add(a, b):
    return a + b

if __name__ == "__main__":
    print(add(2, 3))

Erstelle eine einfachen PyTest Datei für diese App. Diese sollte „test_app.py“ heißen und im gleichen Verzeichnis sein wie die Datei „app.py“:

from app import add

def test_add():
    assert add(2, 3) == 5
    assert add(-1, 1) == 0

from app import add

def test_add():
    assert add(2, 3) == 5
    assert add(-1, 1) == 0

Danach sollte alles auf Git committed werden:

git add .
git commit -m "created app.y and test.py"
git push -u origin main

git add .
git commit -m "created app.y and test.py"
git push -u origin main

Feature auf eigenem Branch entwickeln

Zunächst wird ein neues Feature auf einem neuen Branch entwickelt. Der Branch in Git kann so erstellt werden:

git checkout -b new_feature

git checkout -b new_feature

Es ist dabei sinnvoll folgende Konvention zu befolgen:

• feature/ für neue Features
• fix/ für Bugfixes
• chore/ für organisatorische Änderungen

Die anschließenden Commits zielen nun nicht mehr auf den main-Branch:

git add .
git commit -m "message"
git push -u origin feature/new_feature

git add .
git commit -m "message"
git push -u origin feature/new_feature

Wenn das Feature fertig ist, kann man es in den Main-Branch mergen.

git checkout main
git merge -m "Nachricht" feature/new_feature
git push -u origin main

git checkout main
git merge -m "Nachricht" feature/new_feature
git push -u origin main

Anschließend sollte der Feature-Branch entfernt werden:

git branch -d feature/new_feature
git push origin --delete feature/new_feature

git branch -d feature/new_feature
git push origin --delete feature/new_feature

3. Pull requests

Pull requests dienen dazu, das mergen eines Feature branches vorher überprüfen zu lassen.

Zunächst wird ein neues Feature auf einem neuen Branch entwickelt. Wenn die Entwicklung abgeschlossen ist:

git commit -m "new feature"
git push origin feature/new_feature

git commit -m "new feature"
git push origin feature/new_feature

In GitHub startet man dann einen Pull Request. Hier kann der Code von Teammitgliedern überprüft, kommentiert und ggf. angepasst werden. Wenn alles passt, klickt man in GitHub auf „Merge pull request“.

Moderne Branching-Strategien in professionellen Projekten

In professionellen Softwareprojekten kommt es stark auf eine klare, standardisierte Branching-Strategie an, um Stabilität, Geschwindigkeit und Übersicht im Entwicklungsprozess zu gewährleisten. Im Folgenden ein Überblick über aktuelle state-of-the-art Ansätze, die heute am häufigsten genutzt werden:

GitHub Flow

Der GitHub Flow ist besonders in agilen Teams und bei Continuous Deployment beliebt.
Er ist einfach, schlank und eignet sich hervorragend für Webanwendungen mit häufigen Releases.

main
  \
   \--- feature/login
          \
           (commit)
            \
             --> Pull Request --> Merge --> main --> Deploy

main
  \
   \--- feature/login
          \
           (commit)
            \
             --> Pull Request --> Merge --> main --> Deploy

Ablauf:

1. Alles basiert auf dem main-Branch.
2. Für jedes Feature wird ein kurzer feature/<name>-Branch erstellt.
3. Änderungen werden per Pull Request zurück in main gemerged.
4. Nach dem Merge wird automatisch (z. B. via CI/CD) deployt.

Vorteil: Sehr geringe Komplexität, ideal für Continuous Deployment.
Nachteil: Weniger geeignet für Projekte mit parallelen Versionen oder Release-Zyklen.

GitLab Flow

Der GitLab Flow kombiniert das Beste aus GitHub Flow und GitFlow.
Er integriert Umgebungen (z. B. staging, production) in den Workflow.

main --------------------> staging ------------------> production
   \                        ^
    \                       |
     \--- feature/new_api --/

main --------------------> staging ------------------> production
   \                        ^
    \                       |
     \--- feature/new_api --/

Typischer Ablauf:

• Branches wie feature/*, fix/*, hotfix/* dienen der Entwicklung.
• Merges erfolgen in main oder develop, je nach Stabilität.
• Zusätzlich gibt es environment branches wie staging oder production, die mit bestimmten Deployments verknüpft sind.

Vorteil: Nahtlose Integration mit DevOps-Pipelines und Deployments.
Nachteil: Etwas mehr Struktur nötig als beim GitHub Flow.

Trunk-Based Development

Ein zunehmend populärer Ansatz bei CI/CD-First-Teams (z. B. bei Google, Meta, Spotify).
Hier wird auf kurzlebige Feature-Branches gesetzt, die innerhalb weniger Stunden oder Tage wieder gemerged werden.

main
 |\
 | \___ small_feature (1 day)
 |     /
 |----/----> CI/CD deploys multiple times per day

main
 |\
 | \___ small_feature (1 day)
 |     /
 |----/----> CI/CD deploys multiple times per day

Prinzipien:

• Entwickler arbeiten direkt auf dem main (auch „trunk“) oder in sehr kurzlebigen Branches.
• Jeder Commit wird durch automatisierte Tests und Code Reviews geprüft.
• Deployment erfolgt mehrmals täglich.

Vorteil: Extrem schnelle Integration, ideal für Microservices und Continuous Delivery.
Nachteil: Erfordert disziplinierte Teams und ausgereifte Testautomatisierung.

Weitere nützliche Git-Kommandos

Git Stash

Wenn du an etwas arbeitest, aber kurzfristig auf einen anderen Branch wechseln musst, kannst du uncommittete Änderungen temporär speichern:

git stash

git stash

Änderungen verschwinden aus dem Arbeitsverzeichnis, sind aber sicher zwischengespeichert. Anschließend kannst du z. B. den Branch wechseln.

Wenn du später weitermachen willst:

git stash pop

git stash pop

Git Log

Zeigt die Historie aller Commits an:

git log --oneline --graph --decorate

git log --oneline --graph --decorate

Ideal, um Branch-Verläufe visuell zu überblicken.

Git Diff

Zeigt, was sich seit dem letzten Commit geändert hat:

git diff

git diff

Oder vergleiche zwei Branches:

git diff main..feature/login

git diff main..feature/login

Git Rebase

Der Befehl git rebase wird oft verwendet, um die Commit-Historie linear und lesbar zu halten, insbesondere vor dem Mergen in den main-Branch.

Im Gegensatz zu git merge, das eine neue Merge-Verzweigung erzeugt, „setzt“ git rebase deine Commits auf eine neue Basis – so, als hättest du deine Arbeit auf einem aktuelleren Stand begonnen.

Beispiel: Man arbeitet auf einem Feature-Branch, während der main-Branch weiterentwickelt wurde. Wenn man git merge main ausführt, dann sieht die Historie so aus:

A --- B --- C --- F --- M
       \             /
        D --- E -----

A --- B --- C --- F --- M
       \             /
        D --- E -----

Bit Git Rebase setzt man dagegen die Commits D und E auf F auf:

git checkout feature
git fetch origin
git rebase origin/main

git checkout feature
git fetch origin
git rebase origin/main

Im Ergebnis entstehen D‘ und E‘, eigentlich Kopien der ursprünglichen Commits, aber auf die neue Basis gesetzt:

A --- B --- C --- F --- D' --- E'

A --- B --- C --- F --- D' --- E'

Wichtig: Rebase sollte nicht auf Branches verwendet werden, die bereits geteilt oder gemerged wurden. Es macht nur auf lokalen Branches Sinn.

Git Squash

„Squashen“ bedeutet, mehrere Commits in einen einzigen Commit zusammenzufassen. Das ist nützlich, um kleine, unwichtige Zwischen-Commits zu reduzieren, bevor man in main merged. Wenn man in GitHub einen Pull Request mergt, kannst man statt „Merge commit“ den Modus „Squash and merge“ wählen. Dadurch wird automatisch ein einziger Commit auf main erstellt – selbst wenn dein Feature-Branch aus vielen kleinen Commits bestand. Das ist heute Best Practice in vielen Teams, um eine saubere Main-Historie zu behalten.

Mit interactive rebase geht es so kann man so vorgehen, dass man zunächst die letzten bspw. die 3 Commits auswählt:

git rebase -i HEAD~3

git rebase -i HEAD~3

Im Editor sieht es dann ungefähr so aus:

pick a1b2c3 initial API implementation
pick d4e5f6 add more tests
pick g7h8i9 fix typo

pick a1b2c3 initial API implementation
pick d4e5f6 add more tests
pick g7h8i9 fix typo

Die Zeilen die man zusammenführen möchte, setzt man auf squash:

pick a1b2c3 initial API implementation
squash d4e5f6 add more tests
squash g7h8i9 fix typo

pick a1b2c3 initial API implementation
squash d4e5f6 add more tests
squash g7h8i9 fix typo