Die Welt ist nicht perfekt. Normalerweise kannst du nicht jedes Projekt, mit dem du arbeitest, sofort auf Git umstellen. Manchmal steckt man in einem Projekt mit einem anderen VCS fest und wünscht sich, man könnte zu Git wechseln. Wir werden im ersten Teil dieses Kapitels die Möglichkeiten kennenlernen, Git als Client zu verwenden, falls das Projekt, an dem du gerade arbeitest, ein anderes System nutzt.
Irgendwann wirst du vielleicht dein bestehendes Projekt nach Git migrieren wollen. Der zweite Teil dieses Kapitels behandelt die Migration deines Projekts zu Git aus verschiedenen Systemen sowie eine funktionierende Methode, wenn kein vorgefertigtes Import-Tool vorhanden ist.
Git bietet Entwicklern eine so reizvolle Umgebung, dass viele Anwender schon herausgefunden haben, wie man es auf den Arbeitsplätzen nutzen kann, auch wenn der Rest des Teams ein völlig anderes VCS einsetzt. Es gibt eine Vielzahl dieser Schnittstellen, die sogenannten „Brücken“. Hier werden wir die vorstellen, denen du am ehesten in der „freien Wildbahn“ begegnen wirst.
Wenn du eine bestehende Quelltext-Basis in einem anderen VCS hast, aber dich für die Verwendung von Git entschieden hast, musst du dein Projekt auf die eine oder andere Weise migrieren. Dieser Abschnitt geht auf einige Importfunktionen für gängige Systeme ein und zeigt anschließend, wie du deinen eigenen benutzerdefinierten Importeur entwickeln kannst. Du lernst, wie man Daten aus einigen der größeren, professionell genutzten SCM-Systeme importierst. Sie werden von der Mehrheit der Benutzer, die wechseln wollen genutzt. Für diese Systeme sind oft hochwertige Migrations-Tools verfügbar.
Du solltest jetzt in der Lage sein, Git als Client für andere Versionskontrollsysteme zu verwenden oder fast jedes vorhandene Repository in Git zu importieren, ohne dabei Daten zu verlieren. Im nächsten Kapitel werden wir die internen Abläufe in Git beschreiben, so dass du jedes einzelne Byte nach Bedarf selbst erzeugen kannst.