Auswählen einer Codeflussstrategie

8 Minuten

Es ist wichtig, eine Strategie für den Codefluss auszuwählen, die mit der Arbeitsweise Ihres Teams zusammenpasst. Es stehen mehrere Strategien zur Auswahl. Am Ende des Moduls können Sie die einzelnen Optionen erkunden. Das Tailspin-Webteam entscheidet sich für die Entwicklung einer Codeflussstrategie, die auf Git und GitHub basiert.

Als Mara Azure Boards eingerichtet hat, hat sie zusammen mit dem Team einige anfängliche Aufgaben identifiziert, die berücksichtigt werden müssen. Eine Aufgabe bestand darin, einen Git-basierten Workflow zu erstellen.

Ein Screenshot von Azure Boards, der die ersten drei Aufgaben zeigt

Hören wir dem Team zu, wie es einen besseren Weg zur Zusammenarbeit ausarbeitet. Derzeit wird ein zentralisiertes Versionskontrollsystem verwendet, aber es ist geplant, auf Git, ein verteiltes System, umzusteigen.

Mara arbeitet konzentriert an den ihr zugewiesenen Funktionen, als Andy hereinkommt.

Andy: Hallo Mara. Im Führungskräftetreffen heute Morgen wurde angesprochen, dass unser Team und das Spieleentwicklungsteam unterschiedliche Versionskontrollsysteme verwenden. Um die gemeinsame Nutzung von Ressourcen zwischen den Teams zu rationalisieren, wurden wir gebeten, auf ein verteiltes Versionskontrollsystem umzusteigen, das die Zusammenarbeit besser handhaben kann.

Mara: Das ist gut zu wissen. Wenn Du weißt, haben wir diesen Punkt in unsere Planung aufgenommen. Zurzeit verwenden wir ein zentralisiertes Versionskontrollsystem. Das funktioniert für uns jetzt sehr gut, aber ich stimme zu: Wenn wir anfangen, mit anderen Teams zusammenzuarbeiten und unser Team größer wird, ist ein verteiltes Versionskontrollsystem die bessere Wahl. Eine weitere Aufgabe in unserer Planung besteht darin, die Sichtbarkeit zu erhöhen, sodass alle Beteiligten wissen, woran jeder arbeitet. Ich denke, ein verteiltes Quellcodeverwaltungssystem wie Git würde ebenfalls hilfreich sein.

Andy: Ich wollte Git schon länger ausprobieren. Ich scheine nie Zeit dafür zu haben. Ist das Erlernen oder Einrichten schwierig? Wenn es sich anbietet, können wir vielleicht gleich daran arbeiten. Ich bin es leid, Dinge immer aufzuschieben. Und es wäre schön, wenn wir sehen könnten, was jeder macht und Zugriff auf das gesamte Repository hätten. OK, worum geht es?

Mara: Lass es mich erklären, und dann kannst Du entscheiden, ob es nach etwas klingt, das wir sofort implementieren möchten.

Mara und Andy gehen zum Whiteboard, um Versionskontrolle zu erörtern.

Was ist Git und verteilte Versionskontrolle?

Abbildung: Handgezeichnete Abbildung, in der zentralisierte mit verteilter Versionskontrolle verglichen wird.

Mara: Die Zeichnung auf der linken Seite ist die zentralisierte Versionskontrolle, die wir jetzt verwenden. In der Team Foundation-Versionskontrolle gibt es eine zentrale Version der Codebasis , die alle verwenden. Jeder von uns arbeitet an den Dateien, die wir ändern müssen, und mergt sie dann wieder in das Hauptrepository, wenn wir fertig sind.

Andy: Ja, und das funktioniert für uns. Nun, ausgenommen damals, als ich blockiert wurde, weil ein Breaking Change in das zentrale Repository gemergt wurde.

Mara: Richtig! Sie wurden blockiert . Wir könnten eine Branchingstrategie mit TFVC verwenden, um das Blockierungsproblem zu lösen, aber in unserer aktuellen Konfiguration könnte das Mergen ein wenig komplizierter werden. Und als es zu diesem Breaking Change kam , konnte niemand mehr arbeiten, bis wir das Problem gelöst hatten. Dieses Problem bleibt immer bestehen, da wir alle die gleiche Kopie des Codes verwenden.

Auf der rechten Seite befindet sich eine Zeichnung der verteilten Versionskontrolle. Wir haben immer noch ein Hauptrepository , das die stabile Version der Codebasis ist. Aber jeder Entwickler hat eine eigene Kopie davon, mit der er arbeitet. Dadurch können wir experimentieren und verschiedene Ansätze ausprobieren, ohne dass sich dies auf das Hauptrepository auswirkt.

Die verteilte Versionskontrolle stellt außerdem sicher, dass nur funktionierender Code mit dem Hauptrepository gemergt wird. Wir könnten sie sogar so einrichten, dass der Code erst gemergt werden kann, nachdem er überprüft wurde.

Das Tolle an Azure DevOps ist, dass es sowohl mit zentralisierten als auch verteilten Versionskontrollsystemen funktioniert.

Andy: Was geschieht, wenn mehrere Personen dieselbe Datei ändern?

Mara: Häufig kann Git mehrere Änderungen automatisch mergen. Natürlich möchten wir immer sicherstellen, dass die Kombination von Änderungen zu funktionierendem Code führt. Wenn Git Änderungen nicht automatisch zusammenführen kann, werden Konflikte direkt in den Dateien markiert, sodass ein Mensch entscheiden kann, welche Änderungen er akzeptieren möchte.

Andy: Momentan wird unser Code auf unserem eigenen Server gespeichert. Wenn wir zur Verwendung der verteilten Versionskontrolle wechseln, wo wird der Code gespeichert?

Mara: Gut, dass Du fragst. Hier kommt Hosting ins Spiel.

Wo kann ich mein Repository hosten?

Mara: Bei der Entscheidung, wo unsere Repositorys gehostet werden sollen, stehen einige Optionen zur Auswahl. Beispielsweise können wir sie auf einem lokalen Server, in Bitbucket oder in GitHub hosten. Bitbucket und GitHub sind webbasierte Hostinglösungen. Wir können von überall aus auf sie zugreifen.

Andy: Hast Du eine dieser Optionen bereits verwendet?

Mara: In der Vergangenheit habe ich GitHub verwendet. Es verfügt über Funktionen, die für Entwickler wichtig sind, z. B. einfachen Zugriff auf Änderungsprotokolle und Versionskontrollfunktionen entweder über die Befehlszeile oder das Onlineportal.

Andy: Wie funktioniert Git denn?

Wie arbeite ich mit Git?

Mara: Wie bereits erwähnt, können Entwickler mit verteilten Systemen auf jede beliebige Datei zugreifen, die sie benötigen, ohne die Arbeit anderer Entwickler zu beeinträchtigen, da sie über eine eigene Kopie des Repositorys verfügen. Ein Klon ist Deine lokale Kopie eines Repositorys.

Wenn wir an einer Funktion oder einer Fehlerbehebung arbeiten, möchten wir in der Regel verschiedene Ansätze ausprobieren, bis wir die beste Lösung gefunden haben. Jedoch ist das Testen von Code in Deiner Kopie der Hauptcodebasis keine gute Idee, da Du die ersten Versuche nicht beibehalten möchtest.

Um Dir eine bessere Option zu bieten, verfügt Git über eine Funktion namens Branching, bei der Du beliebig viele Kopien verwalten und nur die gewünschte wieder mergen kannst. So bleibt der Hauptbranch stabil.

Andy: Bis jetzt habe die Konzepte verstanden. Wie checke ich meinen Code ein?

Wie gelangen meine lokalen Änderungen in die Hauptcodebasis?

Mara: In Git wird der Standardbranch oder Stamm in der Regel als main bezeichnet.

Wenn Sie glauben, dass Ihr Code in den main-Branch im Hauptrepository gemergt werden kann, der von allen Entwicklern gemeinsam verwendet wird, erstellen Sie einen so genannten Pull Request. Wenn Sie einen Pull Request erstellen, informieren Sie damit die anderen Entwickler, dass Code bereit für einen Review ist und Sie diesen in den main-Branch mergen möchtest. Wenn Ihr Pull Request genehmigt ist und dann gemergt wird, wird es Teil der zentralen Codebasis.

Wie sieht ein Branching-Workflow aus?

Schritt 1: Wenn Sie mit der Arbeit an einem neuen Feature oder einer Fehlerbehebung beginnen, sollten Sie zunächst sicherstellen, dass Sie mit der neuesten stabilen Codebasis beginnen. Zu diesem Zweck können Sie die lokale Kopie des main-Branches mit der Serverkopie synchronisieren. Dadurch werden alle anderen Entwickleränderungen in Ihre lokale Kopie gepullt, die seit Ihrer letzten Synchronisierung in den main-Branch auf dem Server gepusht wurden.

Abbildung: Pullvorgang aus dem Remotemainbranch in den lokalen Mainbranch.

Schritt 2: Um sicherzustellen, dass Sie nur an Ihrer Kopie des Codes arbeiten, erstellen Sie einen neuen Branch nur für dieses Feature oder diese Fehlerbehebung. Wie Sie sich vorstellen können, kann es schwierig werden, sich viele Branches für all die Dinge zu merken, an denen Sie arbeiten, daher ist eine gute Namenskonvention hier entscheidend.

Bevor Sie Änderungen an einer Datei vornehmen, checken Sie einen neuen Branch aus, damit Sie wissen, dass Sie an den Dateien aus diesem Branch und nicht aus einem anderen Branch arbeiten. Sie können Branches jederzeit wechseln, indem Sie den betreffenden Branch auschecken.

Abbildung: Erstellen eines neuen Branch im lokalen Repository.

Schritt 3: Jetzt können Sie sicher sein, dass Sie alle gewünschten Änderungen vornehmen können, da diese Änderungen nur in Ihrem Branch vorhanden sind. Während Ihrer Arbeit können Sie Ihre Änderungen in Ihren Branch committen, um sicherzustellen, dass Sie keine Arbeit verlieren und die Möglichkeit haben, ein Rollback für Änderungen vorzunehmen, die Sie an früheren Versionen vorgenommen haben. Bevor Sie Änderungen committen können, müssen Sie die Dateien stagen, damit Git weiß, welche Dateien für den Commit bereit sind.

Abbildung: Commits werden im lokalen Branch durchgeführt.

Schritt 4: Der nächste Schritt ist das Pushen oder Hochladen Ihres lokalen Branches in das Remoterepository (z. B. GitHub), damit andere Entwickler sehen können, woran Sie arbeiten. Keine Sorge, dadurch werden Ihre Änderungen noch nicht gemergt. Sie können Ihre Arbeit so oft wie gewünscht pushen. Das ist eine gute Möglichkeit, um Ihre Arbeit zu sichern oder das Arbeiten mit mehreren Computern zu ermöglichen.

Abbildung: Lokale Commits werden in das Remoterepository gepusht.

Schritt 5: Dieser Schritt ist gängig, aber nicht erforderlich. Wenn Ihr Code wie gewünscht funktioniert, können Sie den main-Remotebranch zurück in den lokalen main-Branch pullen oder mergen. Dort sind Änderungen aufgetreten, die noch nicht in Ihrem lokalen main-Branch vorhanden sind. Nachdem Sie den Remote-main-Branch mit Ihrem Branch synchronisiert haben, mergen Sie den lokalen main-Branch in Ihren Arbeitsbranch und testen den Build noch einmal.

Dadurch wird sichergestellt, dass Ihr Feature mit dem neuesten Code funktioniert. Außerdem hilft dies sicherzustellen, dass Ihre Arbeit reibungslos integriert werden kann, wenn Sie Ihren Pull Request einreichen.

Abbildung: Remoteänderungen werden in das lokale Repository gepullt.

Schritt 6: Ihr lokaler Code muss nun committed und in das gehostete Repository gepusht werden. Dies entspricht den Schritten 3 und 4.

Abbildung: Gemergte Commits werden in das Remoterepository gepusht.

Schritt 7: Sie sind endlich bereit, Ihre Änderungen dem main-Remotebranch vorzuschlagen. Zu diesem Zweck reichen Sie einen Pull Request ein. Bei einer Konfiguration in Azure Pipelines oder einem anderen CI/CD-System löst dieser Schritt den Buildprozess aus, und Sie können sehen, wie Ihre Änderungen die Pipeline durchlaufen. Nachdem der Buildvorgang erfolgreich war und andere Entwickler Ihren Pull Request genehmigt haben, kann der Code in den main-Remotebranch gemergt werden. (Es ist immer noch Aufgabe eines Menschen, die Änderungen zu mergen.)

Abbildung: Pull Request aus einem Branch in den Mainbranch.

Andy: Das hört sich alles kompliziert und schwer zu erlernen an.

Mara: Git kann einschüchternd erscheinen, weil es so mächtig ist, aber nachdem Sie den Hang des Flusses bekommen, beginnt es sich natürlich zu fühlen.

Du verwendest nur einige wenige Befehle täglich. Dies ist eine Zusammenfassung:

Kategorie	Aufgabe	Befehl
Repositoryverwaltung	Erstellen eines Git-Repositorys	`git init`
	Herunterladen eines Remoterepositorys	`git clone`
Verzweigung	Erstellen einer Verzweigung	`git checkout`
Stagen und Committen von Änderungen	Anzeigen, welche Dateien geändert wurden	`git status`
	Stagen von Dateien für den Commit	`git add`
	Committen für Dateien in Deinen Branch	`git commit`
Remotesynchronisierung	Herunterladen eines Branches aus einem Remoterepository	`git pull`
	Hochladen eines Branches in ein Remoterepository	`git push`

Andy: Das klingt wie ein guter Ausgangspunkt. Das kriege ich auf jeden Fall hin. Ich kann bei Bedarf anspruchsvollere Befehle erlernen.