So funktioniert Branching mit Bitbucket Cloud
Ziel
In diesem Tutorial lernst du die Grundlagen zum Erstellen, Reviewen und Mergen von Branches mit Git und Bitbucket Cloud.
Zeit
35 Minuten
Zielpublikum
Du verstehst den grundlegenden Git-Workflow bereits.
Dieses Tutorial hilft dir, wenn du den grundlegenden Git-Workflow bereits verstanden hast und mit folgenden Befehlen vertraut bist:
- Klonen: das Remote-Repository in Bitbucket Cloud auf dein lokales System kopieren
- Hinzufügen oder stagen: deine Änderungen auf das Hinzufügen in den Git-Verlauf vorbereiten
- Committen: neue oder geänderte Dateien dem Git-Verlauf des Repositorys hinzufügen
- Pull: Neue Änderungen, die Andere dem Repository hinzugefügt haben, in dein lokales Repository übernehmen
- Push: Änderungen aus deinem lokalen System in das Remote-Repository übernehmen
Wenn du mit den Git-Grundlagen nicht vertraut bist und dir fix das entsprechende Wissen aneignen willst, sieh dir einfach unser Tutorial Git kennenlernen mit Bitbucket Cloud an.
Warum ist Branching wichtig?
Mit Branching kannst du die Vorteile der Versionskontrolle mit Git voll ausschöpfen. Wenn du Branches in Git nutzt, kannst du:
- Mit mehreren Teams gleichzeitig in einem einzigen Repository arbeiten
- Mit Teammitgliedern überall auf der Welt mithilfe von Bitbucket Cloud zusammenarbeiten
- Lasse mehrere Entwicklungslinien gleichzeitig und unabhängig voneinander ohne Code-Freezes ausführen.
Git einrichten
Damit du gleich üben kannst, wie die Arbeit im Team in einem gemeinsamen Bitbucket-Repository abläuft, haben wir dir ein öffentliches Repository zum Forken bereitgestellt.
Was ist ein Fork?
Fork ist eine andere Möglichkeit, Klone oder Kopien zu speichern. Der Begriff Fork (in der Programmierung) leitet sich von einem Unix-Systemaufruf ab, der eine Kopie eines bestehenden Prozesses erstellt. Im Gegensatz zu einem Branch ist ein Fork also unabhängig vom ursprünglichen Repository. Wenn das ursprüngliche Repository gelöscht wird, bleibt der Fork erhalten. Wenn du ein Repository forkst, erhältst du dieses Repository und alle seine Branches.
1. Gehe zu tutorials/tutorials.git.bitbucket.org.
2. Klicke links auf + > Fork this repository (Dieses Repository forken).
3. Gib einen Namen ein, der im Team noch nicht vergeben ist, und klicke auf Fork repository (Repository forken).
4. Erstelle für das Repository ein Verzeichnis, das du leicht aufrufen kannst. Das könnte in etwa wie folgt aussehen:
Lösung anzeigen
Git kennenlernen mit Bitbucket Cloud
Zugehöriges Material
Git-Befehle
$ mkdir test-repositories $ cd test-repositories/ $ test-repositoriesIm Beispiel oben wird das Verzeichnis für die Test-Repositorys mithilfe des Befehls "mkdir" (make directory, Englisch für Verzeichnis erstellen). Anschließend wechselt Git mit "cd" (change directory, Englisch für Verzeichnis wechseln) zu diesem Verzeichnis.
5. Klone das geforkte Repository in das gerade erstellte Verzeichnis. Das wird in etwa wie folgt aussehen:
$ git clone https://dstevenstest@bitbucket.org/dstevenstest/mygittutorial.bitbucket.io.git Cloning into 'mygittutorial.bitbucket.io'... remote: Counting objects: 12392, done. remote: Compressing objects: 100% (12030/12030), done. remote: Total 12392 (delta 8044), reused 564 (delta 360) Receiving objects: 100% (12392/12392), 2.72 MiB | 701.00 KiB/s, done. Resolving deltas: 100% (8044/8044), done. $ cd mygittutorial.bitbucket.io/So wird mit dem "git clone"-Befehl das Repository geklont und das vom Klon erstellte Verzeichnis mygittutorial.git.bitbucket.io angelegt.
Mit dem Branching-Workflow einen Branch erstellen und Änderungen vornehmen
In diesem Branch fügst du eine Notiz zu deiner Website hinzu.
1. Erstelle einen Branch mit dem Befehl "git branch".
$ git branch test-12. Checke mithilfe des Befehls "git checkout" den Branch aus, den du gerade erstellt hast.
$ git checkout test-1 Switched to branch 'test-1'3. Lass dir deine lokalen Branches mit dem Befehl "git branch" auflisten.
$ git branch main * test-14. Füge der Datei editme.htmleine Notiz hinzu. Zum Beispiel mit folgendem Text:
This is a quote, and I like it.
A quote: The Art of Quoting 5. Füge diese Änderung hinzu.
git add editme.htmlBeachte: Deine Änderung wird noch nicht zum Git-Verlauf committet, sondern verbleibt in einem "Wartezustand". Darüber haben wir in Änderungen speichern gesprochen.
6. Committe die Änderung mit einer beschreibenden Commit-Nachricht.
git commit editme.html -m'added a new quote' [test-1 063b772] added a new quote 1 file changed, 3 insertions(+), 3 deletions(-)Hinweis: Die Änderungen erscheinen nun im Git-Verlauf als ein einziger "Commit". Darüber haben wir in Änderungen speichern gesprochen.
7. Pushe diese Änderung mit dem Befehl "git push" zu Bitbucket.
git push fatal: The current branch test-1 has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin test-1Ein Fehler wird gemeldet, weil du den Branch benennen musst, bevor du den neuen lokal erstellten Branch zum ersten Mal pushst.
8. Pushe den Branch und die Änderung mit dem Befehl "git push branch".
$ git push origin test-1 Counting objects: 3, done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 363 bytes | 0 bytes/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: remote: Create pull request for test-1: remote: https://bitbucket.org/dstevenstest/dans.git.bitbucket.org/pull-requests/new?source=test-1&t=1 remote: To https://bitbucket.org/dstevenstest/dans.git.bitbucket.org.git * [new branch] test-1 -> test-1Damit erkennt das System, dass das ursprüngliche Repository das Ziel dieses neuen Branches ist.
9. Öffne dein Tutorial-Repository und klicke auf Branches. Jetzt sollten dir sowohl der Haupt-Branch als auch der Branch "test-1" angezeigt werden. Dies sollte in etwa so aussehen:
Einen Remote Branch erstellen, abrufen und auschecken
Wenn du in einem Team arbeitest, wirst du wahrscheinlich Branches pullen und abrufen, die von anderen Teammitgliedern erstellt und zu Bitbucket gepusht wurden. In diesem Beispiel zeigen wir dir die Grundlagen zum Erstellen von Branches und wie du mit Branches, die andere erstellt haben, arbeiten kannst.
1. Gehe zu deinem Tutorial-Repository in Bitbucket und klicke auf Branches. Dort solltest du in etwa Folgendes sehen:
2. Klicke auf Create branch (Branch erstellen), gib dem Branch den Namen "test-2" und klicke auf Create (Erstellen).
3. Kopiere den Befehl "git fetch" in das Dialogfeld zum Auschecken deines Branches. Dies sollte in etwa so aussehen:
$ git fetch && git checkout test-2 From https://bitbucket.org/dstevenstest/dans.git.bitbucket.org * [new branch] test-2 -> origin/test-2 Branch test-2 set up to track remote branch test-2 from origin. Switched to a new branch 'test-2'4. Gib den Befehl "git branch" in dein Terminal ein. Es wird eine Liste mit Branches angezeigt, die in etwa so aussieht:
$ git branch main test-1 * test-2Der mit einem Stern * markierte Branch ist der aktive Branch. Darauf solltest du in einem Branching-Workflow unbedingt achten.
5. Mit dem Befehl "git status" erhältst du eine Ausgabe dieser Art:
$ git status On branch test-2 Your branch is up-to-date with 'origin/test-2'. nothing to commit, working tree cleanHier siehst du, in welchem Branch du bist, und dass der Branch auf demselben Stand wie dein Remote-Branch (origin) ist.
6. Verwende den Befehl "git checkout", um den Fokus wieder auf deinen anderen Branch zu ändern. Der Befehl sieht dann etwa so aus:
$ git checkout test-1 Switched to branch 'test-1' Your branch is ahead of 'origin/test-1' by 3 commits. (use "git push" to publish your local commits)Einer der wichtigsten Punkte beim Arbeiten mit Branches: Vergewissere dich bei Änderungen, dass du sie auch am richtigen Branch vornimmst.
Änderungen pushen und Pull-Requests erstellen
Jetzt wird es Zeit, deine erste Änderung reviewen zu lassen und den Branch zu mergen.
1. Klicke auf +> Create a pull request (Pull-Anfrage erstellen). Du kannst erkennen, dass test-1 hier als Quell-Branch und main als Ziel-Branch angezeigt wird.
Da wir dieses Repository durch Forking eines bestehenden Repositorys erstellt haben, ist das Ziel auf den Haupt-Branch des Repositorys gesetzt, das wir geforkt haben.
Um dies zu korrigieren, musst du den Ziel-Branch des Repositorys (den Branch, in den du deine Änderungen mergen wirst) von tutorials/tutorials.git.bitbucket.org in dein Repository ändern.
Außerdem kannst du Reviewer aus deinem Team zum Pull-Request hinzufügen. Erfahre mehr über Pull-Requests.
2. Klicke auf Create pull request (Pull-Anfrage erstellen).
3. Um einen Kommentar in der Pull-Anfrage zu verfassen, wähle eine Diff-Zeile aus. (Das ist dort, wo du die Änderung an der Datei editme.html vorgenommenhast.)
4. Klicke oben links auf der Seite auf Approve (Genehmigen). In einer echten Pull-Anfrage gäbe es auch Reviewer, die Kommentare eingeben.
5. Klicke auf Merge (Mergen).
6. (Optional) Ergänze die Commit-Nachricht.
7. Wähle aus den beiden Optionen die Merge-Strategie Merge commit (Commit mergen) aus: Weitere Informationen zu diesen beiden Merge-Strategien findest du hier.
- Merge commit (Commit mergen): Alle Commits aus deinem Quell-Branch werden beibehalten und in den Ziel-Branch eingegliedert. Alternativ kannst du "git merge --no-ff" in die Befehlszeile eingeben.
- Squash: Führt deine Commits zusammen, wenn du den Quell-Branch in den Ziel-Branch mergst. Alternativ kannst du "git merge --squash" in die Befehlszeile eingeben.
8. Klicke auf Commits und du siehst, wie sich der gerade gemergte Branch in die Gesamtheit der Änderungen einfügt.
Einen Branch löschen und den Haupt-Branch in den lokalen Arbeits-Branch pullen
Du hast jetzt den grundlegenden Branching-Workflow abgeschlossen und deine Änderung befindet sich im Haupt-Branch. Zum Schluss erklären wir, wie du den gerade gemergten Branch löschst, den aktualisierten Haupt-Branch pullst und den aktualisierten Haupt-Branch in deinen test-2-Branch mergst.
Warum sollte ich den Branch löschen?
Vergiss nicht, dass Branching in Git nicht dasselbe wie in SVN oder ähnlichen Versionskontrollsystemen ist. Der Unterschied liegt darin, dass du in Git langlebige Branches nutzen kannst, wie etwa einen Haupt- oder einen Entwicklungs-Branch, aber auch kurzlebige Entwicklungs-Branches, wie wir sie in diesem Tutorial zeigen. Daher kann es hilfreich sein, lokale Branches zu löschen, um deine lokale Umgebung sauberer zu halten.
Warum sollte ich den Haupt-Branch pullen und in test-2 mergen?
Bei diesem Beispiel nehmen wir an, dass du an einem Repository arbeitest, an dem auch ein anderes Teammitglied tüftelt. Dabei solltest du Änderungen gelegentlich in deinen Arbeits-Branch pullen, um Merge-Konflikten bei Pull-Requests vorzubeugen.
1. Öffne dein Terminal und führe den Befehl "git status" aus. Das Ergebnis sollte etwa so aussehen:
$ git status On branch test-1 nothing to commit, working tree cleanDu kannst sehen, dass du dich in dem Branch befindest, in dem du gerade deine Änderung vorgenommen hast, und dass du keine Änderungen hast. Wir sind jetzt bereit, diesen Branch zu beseitigen, nachdem wir die Arbeit beendet haben.
2. Wechsle in den Haupt-Branch. Führe dazu den Befehl "git checkout main" aus. Die Ausgabe sollte wie folgt aussehen:
git checkout main Switched to branch 'main' Your branch is up-to-date with 'origin/main'.Siehst du die Nachricht, die anzeigt, dass du auf dem neuesten Stand bist? Das gilt nur für deinen lokalen Branch. Klar, denn du hast gerade eine Änderung in den Haupt-Branch gemergt und diese Änderung nicht vom Remote-Repository in unser lokales System gepullt. Das werden wir als Nächstes tun.
3. Führe den Befehl "git pull" aus. Die Ausgabe sollte wie folgt aussehen:
$ git pull remote: Counting objects: 1, done. remote: Total 1 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (1/1), done. From https://bitbucket.org/dstevenstest/dans.git.bitbucket.org 2d4c0ab..dd424cb main -> origin/main Updating 2d4c0ab..dd424cb Fast-forward editme.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Wenn du die Änderungen aus dem Remote-Repository pullst, führt Git einen Fast-Forward-Merge aus, um deine Änderungen zu integrieren. Dabei wird auch die Anzahl der geänderten Dateien und Zeilen in dieser Datei angezeigt.
4. Führe den Befehl "git branch -d {branch_name}" aus, um den Branch "test-1" zu entfernen. Das Ergebnis wird etwa so aussehen:
$ git branch -d test-1 Deleted branch test-1 (was 063b772)Du siehst, dass der Branch gelöscht wurde und welcher der letzte Commit-Hash für diesen Branch war. Wenn du einen Branch auf diese Weise löschst, bist du auf der sicheren Seite, denn Git lässt nicht zu, dass du einen Branch mit nicht committeten Änderungen löschst. Allerdings hält Git dich nicht davon ab, Änderungen zu löschen, die in den Git-Verlauf committet, aber nicht in einen anderen Branch gemergt wurden.
5. Wechsle mit dem Befehl "git checkout" in den Branch "test-2".
$ git checkout test-2 Switched to branch 'test-2' Your branch is up-to-date with 'origin/test-2'.6. Merge den Haupt-Branch in deinen Arbeits-Branch. Verwende dazu den Befehl "git merge main test-2". Das Ergebnis wird etwa so aussehen:
$ git merge main test-2 Updating 2d4c0ab..dd424cb Fast-forward editme.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Dabei solltest du Folgendes bedenken:
- Auf den aktiven Branch kommt es an. Wenn du den Haupt-Branch in test-2 mergen willst, solltest du test-2 ausgecheckt haben (aktiv). Dasselbe gilt, wenn du test-2 in den Haupt-Branch mergen willst. Auch dann musst du den Haupt-Branch ausgecheckt haben.
- Mit "git branch" kannst du den aktiven Branch anzeigen, der dann mit einem Sternchen markiert ist. Mit "git status" findest du heraus, in welchem Branch du dich befindest und ob lokale Änderungen ausstehen.
Wir hoffen, du hast ein wenig über das Branching und die zugehörigen Befehle gelernt. Rekapitulieren wir das Ganze noch einmal:
Den Branching-Workflow reviewen
Der Feature-Branch-Workflow von Git ermöglicht deinem Team eine effiziente Zusammenarbeit in Bitbucket. In diesem Workflow findet die gesamte Feature-Entwicklung in Branches statt, die vom Haupt-Branch abgetrennt sind. So ist es möglich, dass mehrere Entwickler an ihren Features arbeiten, ohne mit dem offiziellen Code in Berührung zu kommen.
Mit dem Haupt-Branch beginnen
Dieser Workflow hilft dir dabei, mit mindestens einer weiteren Person an deinem Code zu arbeiten. Solange dein Bitbucket und deine lokale Repositorys aktuell sind, kannst du direkt loslegen.
Einen neuen Branch erstellen
Verwende für jedes Feature oder Issue, an dem du arbeitest, einen separaten Branch. Nachdem du einen Branch erstellt hast. checkst du ihn lokal aus, damit alle deine Änderungen auf diesem Branch stattfinden.
Aktualisieren, Hinzufügen, Committen und Pushen von Änderungen
Genau wie mit Git kannst du an Features arbeiten und Commits durchführen. Wenn du fertig bist, pushe deine Commits und der Feature Branch in Bitbucket wird aktualisiert.
Lass deinen Code überprüfen
Um Feedback zu deinem Code zu bekommen, erstellst du einfach eine Pull-Anfrage in Bitbucket. Hier kannst du Reviewer hinzufügen und vor dem Mergen einen letzten Blick auf den Code werfen.
Einarbeiten von Feedback
Jetzt ist es an deinen Teamkollegen, zu kommentieren und zu genehmigen. Bearbeite ihre Kommentare lokal, führe einen Commit durch und pushe Änderungen zu Bitbucket. Deine Updates erscheinen dann im Pull-Request.
Deinen Branch mergen
Vor dem Mergen musst du eventuelle Merge-Konflikte lösen, falls andere Entwickler Änderungen an dem Repository vorgenommen haben. Wenn deine Pull-Anfrage genehmigt wurde und es keine Konflikte gibt, kannst du deinen Code zum Haupt-Branch hinzufügen. Führe das Mergen über die Pull-Anfrage in Bitbucket durch.
Dieses Tutorial kann dir nur begrenzt zeigen, wie Branches Teams effizienter machen. Es gibt verschiedene Branching-Ansätze, die wir teilweise in Workflows im Vergleich vorstellen.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
Bitbucket-Blog
DevOps-Lernpfad
