Die Git-Befehle git reset, git checkout und git revert kann man leicht durcheinanderbringen. Diese Tutorial-Reihe soll helfen, sie voneinander abzugrenzen und Git-Entwickler in die Lage zu versetzen, immer das richtige Kommando für eine spezifische Entwicklungsaufgabe zur Hand zu haben. Nachdem wir uns im ersten Teil git reset näher angesehen haben, widmen wir uns nun dem Auschecken und dem Reverting.

In den beiden ersten Teilen dieser Artikelreihe haben wir uns mit konzeptionellen Fragen rund um git merge vs. git rebase auseinandergesetzt und Möglichkeiten besprochen, um das Rebasing sinnvoll in den Entwicklungs-Workflow mit Git einzubinden. Darauf aufbauend folgen hier nun weitere Anwendungsfälle.

Das Kommando git rebase ist ein Feature für fortgeschrittene Nutzer, das vielfältige Möglichkeiten bietet, aber mit Bedacht eingesetzt sein will. Nachdem wir uns im ersten Artikel mit konzeptionellen Fragen und den Möglichkeiten des interaktiven Rebasings beschäftigt haben, wollen wir nun betrachten, welche Regeln bei der Arbeit mit git rebase einzuhalten sind und wie sich der Befehl sinnvoll in unsere Entwicklungs-Workflows mit Git einbinden lässt.

Der Befehl git rebase hat einen gewissen Ruf als Kommando für Fortgeschrittene, das Git-Einsteiger meiden sollten. Doch git rebase kann einem Entwicklungsteam das Leben deutlich leichter machen, wenn es sorgsam verwendet wird. In diesem Beitrag und folgenden Artikeln wollen wir git rebase mit git merge vergleichen.

Im Zusammenhang mit Branches sieht Git drei zentrale Operationen vor. Nach den ersten beiden Tutorials zum Erstellen von Branches und zum Auschecken von Branches wenden wir uns nun dem Mergen zu. Merging ist in Git der Weg, eine geforkte Historie wieder zusammenzuführen. Der Befehl git merge ermöglicht es uns, die unabhängigen Entwicklungslinien, die wir mit git branch erstellt haben, in einen einzelnen Branch zu integrieren.

Mit dem Befehl git checkout können wir zwischen Branches navigieren, die wir mit git branch erstellt haben. 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. Wie genau das funktioniert, zeigt dieses Tutorial.

Dieses Tutorial bietet eine kompakte Einführung zum Thema Git-Branches. Zunächst soll uns interessieren, wie Branches erstellt werden. Kommende Artikel widmen sich dann dem Auschecken von Branches und dem Mergen, um die Historie eines unabhängigen Branchs zu integrieren.