Freigeben über

Migrieren von der zentralen Versionssteuerung zu Git

Die Migration eines Teams zu Git von der zentralen Versionssteuerung erfordert mehr als nur das Erlernen neuer Befehle. Zur Unterstützung der verteilten Entwicklung speichert Git Dateiverlaufs- und Branchinformationen anders als ein zentralisiertes Versionssteuerungssystem. Die Planung und Implementierung einer erfolgreichen Migration zu Git von einem zentralen Versionskontrollsystem erfordert ein Verständnis dieser grundlegenden Unterschiede.

Microsoft hat bei der Migration vieler interner Teams und Kunden von zentralen Versionskontrollsystemen zu Git geholfen. Diese Erfahrung hat die folgenden Anleitungen basierend auf Praktiken erzeugt, die konsistent erfolgreich sind.

Schritte für eine erfolgreiche Migration

Für eine erfolgreiche Migration sollten Teams:

  • Bewerten sie aktuelle Tools und Prozesse.
  • Wählen Sie eine Git-Verzweigungsstrategie aus.
  • Entscheiden Sie, ob und wie der Verlauf migriert werden soll.
  • Verwalten Sie das vorherige Versionssteuerungssystem.
  • Entfernen Sie Binärdateien, ausführbare Dateien und Tools aus der Quellcodeverwaltung.
  • Schulen Sie Teams in Git-Konzepten und -Praktiken.
  • Testen Sie die Migration zu Git.

Die Bewertung der aktuellen Tools und Prozesse

Das Ändern von Versionskontrollsystemen stört den Entwicklungsworkflow natürlich mit neuen Tools und Methoden. Diese Unterbrechung kann eine Möglichkeit sein, andere Aspekte des DevOps-Prozesses zu verbessern.

Teams sollten die folgenden Methoden bei der Migration zum neuen System in Betracht ziehen:

Auswählen einer Git-Verzweigungsstrategie

Vor der Migration von Code sollte das Team eine Verzweigungsstrategie auswählen.

In Git ermöglichen kurzlebige Themen-Branches Entwicklern, nahe am Haupt-Branch zu arbeiten und schnell integriert zu werden, um Zusammenführungsprobleme zu vermeiden. Zwei gängige Themenzweigstrategien sind GitFlow und eine einfachere Variation, GitHub Flow.

Git rät von langlebigen, isolierten Feature-Branches ab, die dazu tendieren, die Zusammenführung zu verzögern, bis die Integration erschwert wird. Durch die Verwendung moderner CD-Techniken wie Feature-Toggles können Teams Code schnell in den Hauptzweig integrieren, während unfertige Features weiterhin vor den Nutzern verborgen bleiben, bis sie abgeschlossen sind.

Teams, die derzeit eine langlebige Featurezweigstrategie verwenden, können Featurekennzeichnungen übernehmen, bevor Sie zu Git migrieren. Die Verwendung von Featurekennzeichnungen vereinfacht die Migration, indem die Anzahl der zu migrierenden Verzweigungen minimiert wird. Unabhängig davon, ob sie Featurezweige oder Featurekennzeichen verwenden, sollten Teams die Zuordnung zwischen Legacy-Verzweigungen und neuen Git-Branches dokumentieren, sodass jeder versteht, wo sie ihre neue Arbeit übernehmen.

Entscheiden, ob der Verlauf migriert werden soll

Teams könnten versucht sein, ihren aktuellen Quellcodeverlauf nach Git zu übertragen. Mehrere Tools behaupten, einen vollständigen Verlauf aller Verzweigungen von einem zentralen Tool zu Git zu migrieren. Ein Git-Commit scheint relativ gut dem Changeset- oder Check-in-Modell zuzuordnen, das vom vorherigen Versionskontrolltool verwendet wurde.

Diese Abbildung hat jedoch einige schwerwiegende Einschränkungen.

  • In den meisten zentralisierten Versionskontrollsystemen sind Verzweigungen als Ordner im Repository vorhanden. Die Hauptverzweigung kann z. B. ein Ordner mit dem Namen "/trunk" sein, und andere Verzweigungen sind Ordner wie "/branch/one " und "/branch/two". In einem Git-Repository umfassen die Branches das gesamte Repository, daher ist eine 1:1-Übersetzung schwierig.

  • In einigen Versionssteuerungssystemen ist ein Tag oder eine Bezeichnung eine Sammlung, die verschiedene Dateien in der Struktur enthalten kann, sogar Dateien in unterschiedlichen Versionen. In Git ist ein Tag eine Momentaufnahme des gesamten Repositorys zu einem bestimmten Zeitpunkt. Ein Tag kann keine Teilmenge des Repositorys darstellen oder Dateien in verschiedenen Versionen kombinieren.

  • Die meisten Versionssteuerungssysteme speichern Details zur Art und Weise, wie Dateien zwischen Versionen geändert werden, einschließlich fein abgestimmter Änderungstypen wie Umbenennen, Rückgängigmachen und Rollback. Git speichert Versionen als Momentaufnahmen des gesamten Repositorys, und Metadaten zur Art und Weise, wie Dateien geändert werden, sind nicht verfügbar.

Diese Unterschiede bedeuten, dass eine vollständige Verlaufsmigration im besten Fall verlustbehaftet und möglicherweise irreführend ist. Angesichts der Verluste, des Aufwands und der relativen Seltenheit der Verwendung der Chronik wird empfohlen, dass die meisten Teams den Import der Chronik vermeiden. Stattdessen sollten Teams eine Tippmigration durchführen und nur eine Momentaufnahme der neuesten Verzweigungsversion in Git bereitstellen. Für die meisten Teams wird die Zeit am besten für Bereiche der Migration aufgewendet, die eine höhere Rendite für Investitionen haben, z. B. die Verbesserung von Prozessen.

Verwalten des alten Versionskontrollsystems

Während und nach einer Migration benötigen Entwickler möglicherweise weiterhin Zugriff auf den Verlauf der vorherigen Versionssteuerung. Obwohl der Verlauf der vorherigen Versionssteuerung im Laufe der Zeit weniger relevant wird, ist es dennoch wichtig, darauf verweisen zu können. Streng regulierte Umgebungen verfügen möglicherweise über bestimmte gesetzliche und Überwachungsanforderungen für den Versionskontrollverlauf.

Insbesondere für Teams, die nur eine Tippmigration ausführen, wird dringend empfohlen, das vorherige System unbegrenzt beizubehalten. Legen Sie das alte Versionssteuerungssystem nach der Migration auf schreibgeschützt fest.

Große Entwicklungsteams und regulierte Umgebungen können Breadcrumbs in Git platzieren, die auf das alte Versionssteuerungssystem verweisen. Ein einfaches Beispiel ist eine Textdatei, die als erster Commit am Stamm eines Git-Repositorys vor der Tippmigration hinzugefügt wird, die auf die URL des alten Versionssteuerungsservers verweist. Wenn viele Verzweigungen migriert werden, sollte eine Textdatei in jeder Verzweigung erläutern, wie die Verzweigungen aus dem alten System migriert wurden. Breadcrumbs sind auch für Entwickler hilfreich, die mit der Arbeit an einem Projekt beginnen, nachdem es migriert wurde und mit dem alten Versionssteuerungssystem nicht vertraut sind.

Entfernen von Binärdateien und -tools

Das Speichermodell von Git ist für die Versionsverwaltung von Textdateien und Quellcode optimiert, die kompakt und hochkomprimierbar sind. Binärdateien sind in der Regel groß, und sobald sie einem Repository hinzugefügt wurden, verbleiben sie im Repositoryverlauf und in jedem zukünftigen Klon. Aufgrund der Art und Weise, wie Git den Verlauf speichert, sollten Entwickler das Hinzufügen von Binärdateien zu Repositorys vermeiden, insbesondere Binärdateien, die sehr groß oder häufig geändert werden. Die Migration zu Git ist die Möglichkeit, diese Binärdateien aus der Codebasis zu entfernen.

Es wird auch empfohlen, Bibliotheken, Tools und Build-Output aus Repositories auszuschließen. Verwenden Sie stattdessen Paketverwaltungssysteme wie NuGet, um Abhängigkeiten zu verwalten.

Objekte wie Symbole und Grafiken müssen möglicherweise an einer bestimmten Version des Quellcodes ausgerichtet werden. Kleine, selten geänderte Ressourcen wie Symbole belasten nicht unnötig die Versionsgeschichte, und Sie können sie direkt in ein Repository einfügen. Verwenden Sie die Erweiterung Git Large File Storage (LFS), um große oder häufig geänderte Ressourcen zu speichern. Weitere Informationen zum Verwalten großer Dateien in GitHub finden Sie unter Verwalten großer Dateien. Informationen zu Azure Repos finden Sie unter Verwalten und Speichern großer Dateien in Git.

Schulung bereitstellen

Eine der größten Herausforderungen bei der Migration zu Git hilft Entwicklern zu verstehen, wie Git Änderungen speichert und wie Commits den Entwicklungsverlauf bilden. Es reicht nicht aus, ein Spickzettel vorzubereiten, das alten Befehlen Git-Befehlen zuordnet. Entwickler müssen nicht mehr über den Versionskontrollverlauf in Bezug auf ein zentrales, lineares Modell nachdenken und das Verlaufsmodell von Git und das Commit-Diagramm verstehen.

Die Menschen lernen auf unterschiedliche Weise, sodass Sie verschiedene Arten von Schulungsmaterialien bereitstellen sollten. Live, lab-basierte Schulung mit einem erfahrenen Lehrer funktioniert gut für einige Menschen. Das Pro Git-Buch ist ein hervorragender Ausgangspunkt, der kostenlos online verfügbar ist.

Zu den kostenlosen und verfügbaren praxisorientierten Schulungskursen gehören:

Organisationen sollten daran arbeiten, Git-Experten in Teams zu identifizieren, sie zu unterstützen, anderen Zu helfen und andere Teammitglieder zu ermutigen, ihnen Fragen zu stellen.

Testen der Migration

Sobald Teams ihre Prozesse aktualisieren, ihren Code analysieren und ihre Mitglieder schulen, ist es an der Zeit, den Quellcode zu migrieren. Unabhängig davon, ob Sie eine Tippmigration oder einen Migrationsverlauf durchführen, ist es wichtig, eine oder mehrere Testmigrationen in einem Testrepository durchzuführen. Bevor Sie eine endgültige Migration durchführen, stellen Sie folgendes sicher:

  • Alle Codedateien werden migriert.
  • Alle Filialen sind verfügbar.
  • Es gibt keine streuen Binärdateien im Repository.
  • Benutzer verfügen über die entsprechenden Berechtigungen zum Abrufen und Pushen.
  • Builds sind erfolgreich und alle Tests werden bestanden.

Migrieren des Codes

Führen Sie die endgültige Migration außerhalb der Arbeitszeiten durch, idealerweise zwischen Meilensteinen, wenn es natürliche Ausfallzeiten gibt. Die Migration am Ende eines Sprints kann zu Problemen führen, während Entwickler versuchen, die Arbeit abzuschließen. Versuchen Sie, über ein Wochenende zu migrieren, wenn niemand einchecken muss.

Planen Sie einen festen Wechsel vom alten Versionskontrollsystem zu Git. Wenn Sie versuchen, mehrere Systeme parallel zu betreiben, wissen Entwickler möglicherweise nicht, wo oder wie Sie einchecken. Versetzen Sie das alte Versionskontrollsystem in den Schreibgeschützt-Modus, um Verwirrung zu vermeiden. Ohne diesen Schutz kann eine zweite Migration, die Zwischenänderungen umfasst, erforderlich sein.

Der tatsächliche Migrationsprozess variiert je nach System, von dem Sie migrieren. Informationen zum Migrieren von Team Foundation Version Control finden Sie unter Migrieren von TFVC zu Git.

Migrationscheckliste

Arbeitsabläufe im Team:

  • Legen Sie fest, wie Builds ausgeführt werden.
  • Entscheiden Sie, wann Tests ausgeführt werden.
  • Entwickeln Sie einen Veröffentlichungsverwaltungsprozess.
  • Verschieben Sie Code-Reviews zu Pull-Requests.

Verzweigungsstrategie:

  • Wählen Sie eine Git-Verzweigungsstrategie aus.
  • Dokumentieren Sie die Verzweigungsstrategie, warum sie ausgewählt wurde, und wie ältere Verzweigungen zugeordnet werden.

Geschichte:

  • Entscheiden Sie, wie lange das ältere Versionskontrollsystem laufen soll.
  • Identifizieren Sie Branches, die migriert werden müssen.
  • Erstellen Sie bei Bedarf Breadcrumbs, um Technikern bei der Rückkehr zum älteren System zu helfen.

Binärdateien und Tools:

  • Identifizieren Sie, welche Binärdateien und undiffbare Dateien aus dem Repository entfernt werden sollen.
  • Entscheiden Sie sich für einen Ansatz für große Dateien, z. B. Git-LFS.
  • Entscheiden Sie sich für einen Ansatz zur Bereitstellung von Tools und Bibliotheken, z. B. NuGet.

Ausbildung:

  • Identifizieren sie Schulungsmaterialien.
  • Planen Sie Schulungsveranstaltungen, schriftliche Materialien und Videos.
  • Identifizieren Sie Mitglieder des Teams, die als lokale Git-Experten dienen sollen.

Code-Migration:

  • Führen Sie mehrere Testläufe durch, um sicherzustellen, dass die Migration reibungslos verläuft.
  • Identifizieren und kommunizieren Sie eine Umschaltzeit.
  • Erstellen Sie das neue Git-Repository.
  • Legen Sie das alte System auf schreibgeschützt fest.
  • Migrieren Sie zuerst die Hauptzweige, und führen Sie dann alle anderen benötigten Verzweigungen aus.

Nächste Schritte

  • Last updated on