Wie fange ich an, Git für unterschiedliche Codebasen von verschiedenen Servern zu verwenden?

Hintergrund: Ich habe kürzlich eine Reihe von Projekten in meinem Unternehmen geerbt und versuche, einige grundlegende Probleme bei der Behandlung zu lösen. Die früheren Entwickler (die nicht mehr im Unternehmen sind) verwendeten nämlich keine Form der Quellcodeverwaltung, erstellten wenig Dokumentation und verfügten nicht über wirklich gute Entwicklungsprozesse.

Jetzt habe ich drei Server mit Projekten (Entwicklung, Staging, Produktion), die hauptsächlich aus Websites und Anwendungen und Tools bestehen, die für von uns verwendete Anwendungen und APIs von Drittanbietern erstellt wurden, bis hin zu Speichern von SQL-Skripten und anderen Dingen. Mein erster Gedanke war, all dies in Git zu integrieren, bevor Änderungen und Korrekturen vorgenommen werden, aber es fällt mir schwer, den besten Weg zu finden, dies zu tun.

Viele frühere Entwicklungen wurden direkt auf den Produktionsservern durchgeführt, wodurch eine Kluft zwischen den Codebasen der einzelnen Server entstanden ist. Es ist nicht sofort klar, wo all die Unterschiede liegen - ich sehe Fehlerbehebungen auf der Produktionsseite, die nicht auf Entwicklung / Staging übertragen werden, sowie neue Funktionen auf der Entwicklung, die nicht in Richtung Staging / Produktion verschoben wurden .

Frage: Was wäre der beste Weg für mich, diese zu organisieren und in Git zu verschieben? Wie würde ich meine Repos / Zweige strukturieren, um den Unterschieden im Code Rechnung zu tragen?

Ich habe überlegt, die Entwicklung von Klonen des Produktionsservercodes fortzusetzen und die Entwicklungs- / Staging-Codebasen als historische Referenz beizubehalten. Wäre dies möglicherweise ein Anfangspunkt, wenn man bedenkt, dass ich sowieso nichts über den Entwicklungs- / Staging-Code weiß? Ich könnte einfach Repos der Produktionsserver für jede Website, jedes Tool, jeden Skriptsatz usw. erstellen, Zweige für den vorhandenen Entwicklungs- / Staging-Code erstellen, und jede neue Entwicklung würde von der Codebasis des Produktionsservers verzweigen. Macht das Sinn?

Schieben Sie das Produktionsmaterial in den masterZweig eines neuen Repos. Erstellen Sie daraus einen developZweig, und führen Sie dann den Staging-Server darin zusammen. Es kann zu Konflikten kommen, die gelöst werden müssen. Sobald diese behoben sind, erstellen Sie einen weiteren feature_branchvon developund führen Sie den Entwicklungsserver darin ein. Lösen Sie auftretende Konflikte.

Damit stehen Ihnen 3 Zweige zur Verfügung, die Ihre Produktions-, Staging- und Entwicklungsumgebungen darstellen. Produktion -> master, Inszenierung -> develop, Entwicklung -> feature_branch. Die gesamte Entwicklung erfolgt somit am feature_branchesund wird erst dann in den developZweig integriert, wenn die Funktion abgeschlossen, getestet und stabil ist. Da es stabil ist, kann es als Inszenierung verwendet werden. Schneiden Sie einen releaseZweig ab, developwenn Sie bereit sind, ihn freizugeben, binden Sie alle losen Enden zusammen, fügen Sie diesen zusammen master, und dann haben Sie Ihren neuen Produktionsaufbau.

Eine Ihrer ersten Aufgaben nach dem Einrichten sollte darin bestehen, das feature_branchZurück in develop* und dann developwieder in zusammenzuführen master. Beachten Sie, dass der feature_branchCode möglicherweise nicht getesteten Code und Funktionen enthält. Seien Sie daher vorsichtig, wenn Sie ihn in developund dann zusammenführen master. Sobald dies erledigt ist, sollten alle Zweige denselben Code enthalten, und jede Entwicklung, die auf dem Produktionsserver durchgeführt wurde, wird jetzt zurück in den Entwicklungsserver portiert.

In diesem Modell befindet sich jedes Projekt in einem eigenen Repo, und dieses Repo verfügt über einen Zweig masterund einen developZweig sowie feature_branchesfür alle ausgeführten Arbeiten.

BEARBEITEN, um Kommentare zu adressieren: Ja, das ist Gitflow.

Diese Strategie (oder Gitflow im Allgemeinen) behält das vorhandene 3-Ebenen-System (Produktion, Staging, Entwicklung) mit einem klaren Zusammenführungspfad von der Entwicklung bis zur Produktion bei. Durch den Import der Codebasen auf diese Weise können auch die Zweige synchronisiert werden, während der Status Quo in der Produktion beibehalten wird - zumindest bis die Zusammenführungen getestet werden können. Damit werden einige Ziele erreicht: Der Code wird in der Quellcodeverwaltung gespeichert, die verschiedenen Codebasen werden synchronisiert und zusammengeführt (es gibt also keine Bugfixes mehr in der Produktion, aber keine Entwicklung mehr) und es wird ein nützlicher Prozess für die Zukunft bereitgestellt (ein Prozess, der gut definiert ist und von vielen Menschen / Teams / Unternehmen verwendet). Wenn das OP feststellt, dass Gitflow für seine Projekte / Teams / Unternehmen nicht gut geeignet ist, während er es verwendet / das Unternehmen wächst, dann ist es '

* Möglicherweise möchten Sie einen anderen Feature-Zweig ausschneiden, alle offensichtlichen neuen Features entfernen und diesen Zweig in develop(und dann in master) zusammenführen. Dies verhindert, dass Sie zusätzlich zu allen anderen Tests, die Sie durchführen, neue Funktionen testen müssen.

Ich werde den stagingCode als beste Basis für Ihren ersten Import empfehlen . Das liegt daran, dass es Änderungen productiongibt staging, die aufgrund der Hotfixes nicht vorhanden sind, aber weitaus weniger, wenn Änderungen stagingdaran nicht vorhanden sind production. Ebenso gibt es Änderungen in development, die nicht in staging, aufgrund der neuen Funktionen, aber wahrscheinlich weit weniger , wenn Änderungen in stagingdenen nicht sind development.

Beachten Sie , Sie nicht wollen stagingBaseline nach dem ersten Import sein. Dies ist nur eine vorübergehende Situation, da Änderungen zuvor nicht verfolgt wurden. Verzweigungsvorgänge laufen viel reibungsloser ab, wenn Sie Änderungen hinzufügen , anstatt sie zu entfernen. Wechseln Sie nach dem ersten Import zu einem Verzweigungsmodell, das Ihren Anforderungen am besten entspricht.

Überprüfen Sie also Ihren stagingCode in einem stagingZweig, git checkout -b master stagingerstellen Sie dann einen masterZweig und checken Sie dort Ihren Produktionscode ein. Führen Sie dann eine aus git checkout -b development staging, um Ihren developmentZweig zu erstellen , und überprüfen Sie dort Ihren Entwicklungscode.

Jetzt ist Ihre Besuche developmentZweig und verschmelzen master in ihm. Auf diese Weise können Sie die wahrscheinlich große Menge an Zusammenführungskonflikten lösen und gleichzeitig masteraufzeichnen, was tatsächlich in der Produktion ist. developmentEnthält jetzt alle Änderungen aus jeder Umgebung. Sie können jetzt zu dem für Sie am besten geeigneten Verzweigungsmodell wechseln.

Es ist eine gute Idee, die Geschichte zu haben. Ich würde das Repository (oder eines für jedes Produkt) aus der stabilsten Umgebung erstellen. Erstellen Sie Zweige oder Unterschiede für die anderen.

Auf hohem Niveau:

1. Erstellen Sie ein neues Repo
2. Aus einer produktionsbasierten Arbeitskopie: Alle hinzufügen, festschreiben und pushen
3. Checkout-Master in ein neues Verzeichnis
4. Für jede weitere Umgebung XYZ
   1. Zweig erstellen Archive-XYZ
   2. Ersetzen Sie alles durch XYZQuelle (außer .git)
   3. Alles hinzufügen, festschreiben und pushen

Alternativ, wenn Sie dem Wert davon skeptisch gegenüberstehen, git diff > XYZ.diffanstatt sich tatsächlich zu verpflichten und zu pushen und die Unterschiede zu archivieren.

In beiden Fällen sollten Sie in einem Zustand enden, in dem Sie den in jeder Umgebung ausgeführten Code leicht vergleichen können, um einen einzelnen Startpunkt für jedes Projekt festzulegen. Und wenn etwas kaputt geht, können Sie Ihre Änderungen theoretisch mit einer der drei Umgebungen vergleichen.