Mit dem Befehl git checkout können wir zwischen Branches navigieren, die wir mit git branch erstellt haben (siehe Teil 1 dieses Tutorials). Das Auschecken eines Branchs aktualisiert das Arbeitsverzeichnis, sodass es mit der Version übereinstimmt, die in diesem Branch gespeichert ist, und sagt Git, dass alle neuen Commits auf diesem Branch festgehalten werden sollen. Das können wir uns als einen Weg vorstellen, die Entwicklungsslinie auszuwählen, an der wir arbeiten.
Beim Auschecken von Branches wird das Arbeitsverzeichnis in Übereinstimmung mit dem gewählten Branch gebracht; neue Änderungen werden in der Projekthistorie gespeichert. Es handelt sich also nicht um eine Read-only-Operation.
Nutzung
git checkout <existing-branch>
Checkt den spezifischen Branch aus, der mit git branch erstellt wurde. <existing-branch> wird zum aktuellen Branch, das Arbeitsverzeichnis wird synchronisiert.
git checkout -b <new-branch>
Erstellt <new-branch> und checkt diesen aus. Die Option -b sagt Git bequemerweise, dass es git branch <new-branch> ausführen soll, ehe git checkout <new-branch> ausgeführt wird.
git checkout -b <new-branch> <existing-branch>
Dasselbe wie oben, außer dass wir den neuen Branch von <existing-branch> abzweigen statt vom aktuellen Branch.
Hinweise
git checkout arbeitet Hand in Hand mit git branch. Wenn wir mit einem neuen Feature beginnen wollen, erstellen wir mit git branch einen Branch und checken ihn mit git checkout aus. Wir können in einem Repository an diversen Features arbeiten, indem wir mit git checkout zwischen ihnen wechseln.
Master auschecken
Feature auschecken
Für jedes neue Feature einen eigenen Branch zu haben, ist ein fundamentaler Unterschied zum traditionellen SVN-Workflow. Es ist denkbar einfach, an Dingen herumzuexperimentieren, ohne befürchten zu müssen, bestehende Funktionalität kaputtzumachen, und wir können an beliebig vielen Features gleichzeitig arbeiten. Außerdem unterstützen Branches diverse Kollaborations-Workflows.
Abgetrennter HEAD-Status
Nachdem wir die drei wesentlichen Anwendungsfälle von git checkout kennen, sollten wir uns mit dem abgetrennten HEAD-Status beschäftigen. Der HEAD ist Gits Weg, um auf den aktuellen Snapshot Bezug zu nehmen. Intern aktualisiert der Befehl git checkout einfach den HEAD, um entweder auf den spezifischen Branch oder den Commit zu zeigen. Wenn er auf einen Branch zeigt, beschwert Git sich nicht, aber wenn wir einen Commit auschecken, wechselt es in einen abgetrennten HEAD-Status.
Attached HEAD
Detached HEAD
Dies dient als Warnung, um uns zu sagen, dass alles, was wir tun, vom Rest der Projektentwicklung abgetrennt ist. Wenn wir mit der Entwicklung eines Features beginnen würden, während ein abgetrennter HEAD-Status vorliegt, würde uns kein Branch erlauben, zu ihm zurückzukehren. Wenn wir notwendigerweise einen anderen Branch auschecken (z.B. um das Feature in ihn zu mergen), gäbe es keinen Weg, unser Feature zu referenzieren:
Die Sache ist die, dass unsere Entwicklung immer in einem Branch stattfinden sollte. Das stellt sicher, dass es immer eine Referenzierung auf unsere neuen Commits gibt. Lediglich wenn wir gerade nach einem alten Commit suchen, spielt es eigentlich keine Rolle, ob ein abgetrennter HEAD-Status vorliegt oder nicht.
Beispiel
Das folgende Beispiel demonstriert den grundsätzlichen Branching-Prozess mit Git. Wenn wir mit der Arbeit an einem neuen Feature beginnen wollen, erstellen wir dafür einen Branch und checken ins aus:
git branch new-feature
git checkout new-feature
Dann können wir neue Snapshots committen:
# Edit some files
git add <file>
git commit -m "Started work on a new feature"
# Repeat
All dies wird im Branch new-feature festgehalten, der vollständig vom master isoliert ist. Wir können so viele Commits hinzufügen, wie wir wollen, ohne uns Sorgen darum machen zu müssen, was in den anderen Branches vor sich geht. Wenn wir soweit sind, wenden wir uns wieder der offiziellen Codebasis zu und checken einfach den master-Branch aus:
git checkout master
Dies zeigt uns den Status des Repositorys, bevor wir mit der Arbeit an dem Feature begonnen haben. Von hier aus können wir das fertiggestellte Feature mergen, einen neuen Branch für ein weiteres, unabhängiges Feature abspalten oder an der stabilen Version unseres Projekts arbeiten.
Im dritten Teil dieses Tutorials widmen wir uns dem Kommando git merge.
Weiterführende Infos: Ihr Partner für Git und Stash
Kennen Sie Stash, Atlassians Git-Repository-Managementsystem? Stash bietet eine zentrale Lösung zum Management des gesamten distributierten Codes: Hier kommen alle Git-Repositories im Unternehmen zusammen, hier finden Entwickler immer die letzte offizielle Version eines Projekts, hier können Projektverantwortliche Berechtigungen kontrollieren, um sicherzustellen, dass die richtigen Nutzer Zugriff auf den richtigen Code haben.
Möchten Sie mehr erfahren? Wir sind offizieller Vertriebspartner von Atlassian und einer der größten Atlassian Experts Partner weltweit. Gerne unterstützen wir Sie bei der Evaluierung, Lizenzierung und Adaption von Stash. Und wenn Sie Atlassian-Lizenzen bei //SEIBERT/MEDIA kaufen, gewähren wir Ihnen einen Rabatt in Höhe von 10% der Lizenzkosten in Form von Beratungsleistungen. Bitte sprechen Sie uns einfach an.
99 Argumente für Stash als Git-Repository-Manager
Branch-basierte Git-Workflows mit Stash adaptieren
Echte Integration: Das Zusammenspiel von JIRA, Stash und Bamboo
Interview: Die Vorteile von Git in der Software-Entwicklung und die Möglichkeiten von Stash
So funktioniert die Lizenzierung von Atlassian-Produkten
