Grundlegendes zur Zuordnung von Befehlen der Team Foundation-Versionskontrolle (TFVC) zu Git-Workflows
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Visual Studio 2019 | Visual Studio 2022
Planen Sie die Einführung von Git, sind Sie mit den TFVC-Aktionen vertraut und fragen Sie sich, wie diese in Git zugeordnet werden können? Beides sind leistungsstarke und ausgereifte Quellcodeverwaltungssysteme. Die Zuordnung allgemeiner Aktionen, an die Sie sich im einen System gewöhnt haben, kann jedoch eine verwirrende Erfahrung sein.
Dieser Artikel befasst sich nicht ausführlich mit den Git-Befehlen, da diese in der Produktdokumentation gut dokumentiert sind, sondern zeigt Beispiele, die Ihnen helfen, die richtigen Entscheidungen zu treffen, während Sie einen typischen Workflow zum Erstellen –> Klonen –> Branchen –> Ändern –> Committen –> Pushen durchlaufen.
Beginnen Sie mit dem Erstellen eines neuen Repositorys.
Jedes Projekt kann TFVC- und Git-Repositorys im selben Projekt hosten und dabei ein TFVC- und mindestens ein Git-Repository erstellen.
Nachdem das Repository erstellt wurde, erhalten Sie Schritt-für-Schritt-Anleitungen, damit Sie schnell einsteigen können.
Klicken Sie am Ende der Anleitungsseite auf Create a ReadMe file (Infodatei erstellen), um dem Repository Kontext zu geben und einen Verlauf zu erstellen.
Erstellen eines Arbeitsbereichs und Abrufen des neuesten Codes
Wenn Sie zum ersten Mal eine Verbindung mit einem TFVC-Repository herstellen, erstellen Sie in der Regel einen Arbeitsbereich und rufen den neuesten Code. Wie führen Sie also erste Schritte in Git aus?
Ähnlich wie bei einem Arbeitsbereich in TFVC verwenden Sie clone, um das Git-Repository in einen Ordner auf Ihrem Computer zu klonen. Beim Klonen werden alle Inhalte und der Verlauf des Repositorys auf Ihren lokalen Computer heruntergeladen. Sobald Sie über das geklonte Repository verfügen, werden fast alle Vorgänge lokal ausgeführt. Sie können offline mit einer vollständigen Sicherung des zentralen Repositorys arbeiten.
git clone https://dev.azure.com/demo-fabrikam/Fabrikam/_git/Mapping-TFVC-actions-to-Git
Sie müssen nur ein Mal pro Repository klonen, aber wie bei TFVC-Arbeitsbereichen können Sie mehrere Klone verwenden, um laufende Aufgaben zu isolieren. Branchen ist jedoch in der Regel eine bessere Möglichkeit, Änderungen zu isolieren.
Erstellen einer Verzweigung
Mit Git arbeiten Sie immer in einem Branch und standardmäßig im main-Branch. Es wird empfohlen, mehrere lokale Branches zu erstellen. Es handelt sich um einen Prozess, der nur Sekunden in Anspruch nimmt und es Ihnen ermöglicht, einen nahtlosen Kontextwechsel zwischen Branches durchzuführen und isoliert zu arbeiten. Im Gegensatz zu TFVC-Branches, die auf Pfade ausgerichtet sind, sind Git-Branches für Repositorys gültig. Sie sind einfach, können nur lokal sein oder für andere Benutzer freigegeben werden, wenn Sie bereit sind, Ihre Änderungen zu teilen.
Erwägen Sie Branchen, wenn Sie isoliert arbeiten müssen, Ihre Arbeit anhalten müssen, sich auf neue Features konzentrieren müssen oder wenn Sie planen, einen Git-Pull Request durchzuführen.
Wiederholen Sie dies als TFVC-Benutzer einige Male:
- Branchen wird empfohlen!
- Git-Branching ist kostengünstig, schnell und leistungsstark!
- Git empfiehlt Ihnen, lokale Branches zu verwenden.
- Veröffentlichen Sie nach Bedarf lokale Branches in Ihrem zentralisierten Repository.
- Überprüfen Sie immer den Branchkontext, bevor Sie Änderungen vornehmen.
- Benennen Sie den Branch mithilfe einer allgemeinen Konvention wie users/alias/branchname, z. B.: users/doris/newfeature.
Erstellen Sie einen lokalen Themenbranch namens francis/demo-feature, und navigieren Sie zu diesem. Es empfiehlt sich, zunächst git status auszuführen, um zu überprüfen, ob Sie sich im richtigen Branch befinden, mit dem Sie beginnen möchten.
git checkout -b francis/demo-feature
Vornehmen einer Änderung durch Hinzufügen von Dateien
Ähnlich wie bei TFVC werden neue Dateien im Arbeitsordner nicht automatisch zu Teilen des Repositorys. Sie stellen Ihre neuen Dateien mit dem Befehl git add bereit, der mit dem Ausführen eines add Items to Folder-Vorgangs in TFVC synonym ist.
git add <file>
oder
git add --all
Mit dem vorab erstellten Beispiel verfügen Sie über 13 neue Dateien, die im lokalen Repository enthalten sind und gestaget wurden.
Anzeigen ausstehender Änderungen
Fragen Sie sich, welche Änderungen in Ihrer Arbeitsumgebung jetzt vorhanden sind? Wie zuvor zeigt der Git-Befehl status oder die Changes-Ansicht in der Visual Studio-IDE Änderungen in Ihrer Arbeitsstruktur an.
git status
Einchecken von Änderungen und lokales Committen
In TFVC teilen Sie Ihre Änderungen, indem Sie sie einchecken. Dadurch werden Ihre ausstehenden Änderungen an den Server gesendet. Der Git-Prozess ist etwas anders. Zunächst committen Sie in das lokale Repository und erstellen so ein Commitobjekt (z. B. ein Changeset), dann pushen Sie diese Änderungen auf den Server.
Sie committen die Änderungen in Ihr lokales Repository mit git commit, ähnlich wie Checkin Pending Changes in TFVC. Ein wichtiger Unterschied besteht darin, dass git commit Ihre Änderungen in das lokale Repository anstelle des Remoterepositorys committet.
git commit
Einchecken von Änderungen mit dem Server/Remoterepository
Zunächst müssen Sie Ihren lokalen francis/demo-Featurebranch auf dem Remoteserver veröffentlichen, der alle committeten Änderungen enthält.
git push --set-upstream origin francis/demo-feature
Um weitere Updates in Ihrem lokalen Repository mit dem Remoterepository zu synchronisieren, müssen Sie Ihre Änderungen mithilfe von git push pushen. Es wird empfohlen, den git-Befehl oder die Visual Studio-IDE zu verwenden:
fetch, um Inhalte herunterzuladen und eine Vorschau eingehender Änderungen von anderen Benutzern anzuzeigen.pull, um Änderungen von anderen Benutzern herunterzuladen und dann zu mergen.push, um Ihre lokalen Änderungen zu teilen.
Anzeigen des Verlaufs
Um den soeben erstellten Commit anzuzeigen, können Sie den lokalen Verlauf überprüfen.
Verwenden Sie Folgendes für einen kompakten Verlauf:
git log --oneline
Verwenden Sie Folgendes für eine detaillierte Ansicht:
git log
Wie oben gezeigt, listet git log den Autor, die E-Mail-Adresse, das Datum des Schreibens und die SHA-1-Prüfsumme des Commits auf. Als TFVC-Benutzer möchten Sie ggf. die Option --stat verwenden, um weitere Informationen wie Dateinamen und Änderungsstatistiken einzubinden.
Sie können den Verlauf des zentralisierten Repositorys auch über das Azure DevOps Services-Webportal anzeigen.
Wählen Sie im Azure DevOps Services-Webportal CODE > Verlauf oder CODE > Explorer > Verlauf aus.
An diesem Punkt haben Sie den Workflow zum Erstellen –> Klonen –> Branchen –> Ändern –> Committen –> Pushen basierend auf allgemeinen TFVC-Aktionen erfolgreich untersucht.
Sie haben auch die Möglichkeit, einen Pull Request auszugeben, um Ihre Änderungen an diesem Punkt auf dem Server bzw. im Remoterepository zu veröffentlichen und zu stagen.
Andere Aktionen
Wechseln von Branches
Wenn Sie mit Git arbeiten, ändern Sie keine Branches, indem Sie zu separaten Ordnern und Speicherorten auf Ihrem Computer navigieren. Sie ändern den Kontext, indem Sie einen checkout-Vorgang ausführen, damit das gesamte Arbeitsverzeichnis mit dem ausgewählten Branch oder Commit übereinstimmt. Schnell und einfach!
Befehlszeile
git checkout <branch>
Wenn Sie vergessen haben, welche Branches in Ihrem lokalen Repository enthalten sind, verwenden Sie git branch, um die Standard- und bekannten Branches aufzulisten.
Merken Sie sich, an welchem Branch Sie arbeiten! Wenn Sie mit mehreren Branches in Git arbeiten, wechseln Sie im selben Arbeitsverzeichnis direkt zwischen Branches. Der Wechsel zwischen Branches ist ein schneller Vorgang, und es empfiehlt sich, sicherzustellen, dass Sie sich jederzeit im richtigen Branch befinden.
Letzte Version abrufen
Es gibt viele Gründe, die für Aktualisierungen sprechen. Wenn Sie beispielsweise den Kontext zu einem anderen Projekt wechseln müssen, aktualisieren Sie Ihren Entwicklungscomputer mit der neuesten Version der Codebasis.
Befehlszeile
git pull
oder
git fetch
gefolgt von
git merge FETCH_HEAD
Rufen Sie immer die neueste Version ab, und lösen Sie Mergekonflikte lokal.
Rückgängigmachen lokaler Änderungen
Es kann einen triftigen Grund geben, alle Revisionen, die Sie in Ihrem lokalen Repository vorgenommen haben, rückgängig zu machen und Ihre Arbeitsumgebung auf die neueste Version aus dem Remoterepository zurückzusetzen.
Befehlszeile
git reset --hard HEAD
gefolgt von
git pull origin
gefolgt von
git clean -xdf
Das Szenario ist gleichbedeutend mit Get > Latest Version mit den Optionen Overwrite writable files that are not checked out und Overwrite all files if the local version matches the specified version in TFVC.
Alternativ können Sie ihr lokales Repository manuell löschen – natürlich nachdem Sie eine überprüfte Kopie erstellt haben – und das Repository dann mit clone erneut klonen.
Git-Benutzern stehen viel mehr Aktionen und Optionen zur Verfügung. Hier sind einige nützliche Referenzwebsites für die weitere Lektüre:
- Git-Befehle, die hier behandelt werden, finden Sie in der Git-Dokumentation.
- Think like (a) Git (Denke wie (ein) Git), ein Leitfaden für die Verwirrten.
- How to undo (almost) anything with Git (Wie man (fast) alles mit Git rückgängig machen kann) von Joshua Wehner
Fragen und Antworten
Was ist mit Synchronisierung?
„Macht Commit and Sync der Visual Studio-IDE all dies nicht auf magische Weise?“ fragen Sie sich vielleicht.
Wählen Sie Git>Committen oder stashen aus, um Git-Änderungen zu öffnen. Wählen Sie das Dropdownmenü Alle committen und dann Alle committen und synchronisieren aus.
Oder wählen Sie in Team Explorer das Dropdownmenü Committen und dann Befehl und Synchronisierung aus.
Magie bringt Verantwortung mit sich! Viele Benutzer mögen die Synchronisierung (sync) nicht, weil sie manchmal Ihren lokalen Verlauf durcheinander bringen und einen Mergecommit über Ihrem aktuellen Commit hinzufügen kann. Sobald ein fehlerhaftet Zustand vorliegt, müssen Sie auf die Befehlszeile zurückgreifen, weil es derzeit keine Unterstützung für Zurücksetzen in der IDE gibt.
Autoren: Jesse Houwing, Martin Hinshelwood, Mike Fourie und Willy Schaub von ALM | DevOps Rangers. Stellen Sie hier eine Verbindung mit ihnen her.
(c) 2015 Microsoft Corporation. Alle Rechte vorbehalten. Dieses Dokument wird „wie besehen“ zur Verfügung gestellt. Die in diesem Dokument enthaltenen Informationen und zum Ausdruck gebrachten Ansichten, auch URL- und andere Internet-Websitebezüge, können ohne vorherige Ankündigung geändert werden. Sie tragen das alleinige Verwendungsrisiko.
Dieses Dokument stellt keinerlei Rechtsansprüche auf geistiges Eigentum in Microsoft-Produkten jeglicher Art bereit. Dieses Dokument darf für interne Referenzzwecke kopiert und verwendet werden.