Eine Einführung in die Versionskontrolle und Git

Sind Sie mit Google Docs vertraut? Nun, wenn Sie es sind, können Sie davon ausgehen, dass Sie mit der kleinen Registerkarte "Versionsverlauf" vertraut sind, die es den Autoren und den beteiligten Personen ermöglicht, alle Änderungen, die im Dokument vorgenommen wurden, zu überprüfen und zu verfolgen. zu jedem beliebigen Zeitpunkt. Ein praktisches Werkzeug, nicht wahr?

Stellen Sie sich nun vor, dass es anstelle eines Blattes voller Absätze Dateien mit Hunderten von Codezeilen gibt. Und im Gegensatz zu einem einzelnen Dokument gibt es unzählige verschiedene Dateien, die ständig aktualisiert werden.

In einem Szenario wie diesem, in dem Tausende von Codezeilen im Spiel sind und das Endergebnis, dh die mobile App, das ist, wovon die Zukunft eines Unternehmens abhängt, wird es noch wichtiger, eine Software zu haben, die alle Änderungen im Auge behält in den Codedateien gemacht.

Hier kommt eine Versionskontrollsoftware ins Spiel.

Warum ist Versionskontrolle in der Softwareentwicklung wichtig?

Wie der Name schon sagt, ermöglicht eine Versionskontrollsoftware den Entwicklern mobiler Apps, die verschiedenen Versionen des Softwareentwicklungszyklus zu verfolgen und Änderungen daran vorzunehmen. Diese Möglichkeit, alle Änderungen im Code nachzuverfolgen, und die Möglichkeit, die Änderungen rückgängig zu machen, macht die Versionskontrolle zu einem wichtigen Teil des Prozesses eines Entwicklungsunternehmens für mobile Apps, an dem mehrere Entwickler beteiligt sind.

Wenn es um die Versionskontrolle geht, gibt es derzeit eine Reihe von Software auf dem Markt. Sehen wir uns einige davon an –

Verfügbare Software für die Versionskontrolle

Obwohl der Marktführer für verteilte Software in seiner GitLab-Umfrage feststellte, dass 98 % der Benutzer die Git-Open-Source-Tools verwenden und über 92 % der Entwickler Git als Versionskontrollsprache im App-Entwicklungsprozess verwenden, gibt es eine Reihe der Gründe, warum Entwickler eine Git-Alternative in Betracht ziehen könnten. Einige dieser Gründe können variieren von – der GitHub-Preisstruktur und der Tatsache, dass Github sowohl auf iOS als auch auf Android gestartet wird, einer Abneigung gegen Octocat oder einem einfachen Komfortniveau mit einer Versionskontrollsprache, die nicht Git ist.

Was auch immer Ihr Grund sein mag, hier sind die Alternativen von Git für die Versionskontrolle –

Auch wenn es eine Reihe von Alternativen für die Versionskontrolle gibt und wir bei Appinventiv aus erster Hand Erfahrungen mit der Arbeit an vielen von ihnen haben, sind wir aufgrund unterschiedlicher Kundenanforderungen in der Tat parteiisch gegenüber Git. Lassen Sie mich Ihnen sagen, warum.

Warum Appinventiv Git zur Versionskontrolle verwendet

1. Für seine Blitzgeschwindigkeit

Von allen Versionskontrollsoftware auf dem Markt ist die Geschwindigkeit, mit der Git Log- und Commit-Elemente arbeiten, mit keiner anderen vergleichbar. Und wenn Ihr Entwicklerteam an einer Plattform arbeitet, ist es absolut notwendig, dass die Software schnell ist.

2. Für die Fähigkeit, offline zu arbeiten

Wenn Sie an einer Software arbeiten, die auf das Internet angewiesen ist, kann es riskant sein, wenn Sie unterwegs sind und die Verbindung zum zentralen Repository verlieren. Dies ist jedoch bei Git nicht der Fall. Mit Git können Sie fast alle Aufgaben auf Ihrem lokalen Rechner erledigen – committen, den Projektverlauf durchsuchen, Zweige erstellen oder zusammenführen.

3. Für das Undo-Relief

Git enthält einen „Undo“-Befehl, mit dem Sie den gesamten Commit korrigieren und rückgängig machen können. Tatsächlich gibt es Ihnen sogar die Möglichkeit, den „gelöschten“ Commit über seine Reflog-Option wiederherzustellen.

4. Für die Sicherung

Wenn das Team an Git arbeitet, enthält jeder einzelne Klon, den das Team auf seinem Computer hat, ein brauchbares Backup. Darüber hinaus fügt fast jede einzelne Git-Aktion die Daten nur hinzu und löscht sie nicht.

5. Für nützliche Verpflichtungen

Wenn unser Entwicklerteam eine Reihe von nicht zusammenhängenden Änderungen festschreibt – einige Funktionen von A übernimmt, einige Bugfixes in einem anderen vornimmt – kann es für die anderen Teammitglieder sehr schwierig sein, zu verstehen, was passiert ist, und es kann für sie schwierig sein, einen Rollback durchzuführen A's Funktionen, wenn es Probleme verursacht.

Git löst dieses Durcheinander, indem es ein granulares Commit erstellt. Durch das „Staging Area“-Konzept kann man leicht herausfinden, welche Änderungen im nächsten Commit enthalten sein würden, selbst wenn man sich nur noch einzelne Zeilen ansehen muss.

Das waren also die fünf Hauptgründe, warum wir Git hier bei Appinventiv verwenden. Nachdem wir uns nun mit dem Warum befasst haben, ist es an der Zeit, sich mit dem Wie zu befassen. Wie wir Git in unseren Versionskontrollprozess integrieren.

Kommen wir jetzt dazu.

Ablauf der Versionskontrolle bei der Verwendung von Git

Repository-Erstellung

Das Ziel von Git ist es, eine Reihe von Dateien, auch bekannt als Project, zu verwalten. Dazu speichert Git alle Informationen in einer Datenstruktur, die als Repository bekannt ist. Ein Repository besteht aus den Quellcodes der App, den Ressourcen und den Datensätzen. Im Grunde hat es alles, was das App-Projekt ausmacht.

Nun gibt es zwei Möglichkeiten, ein Repository auf Git zu bekommen. Sie können entweder ein lokales Verzeichnis verwenden und es über die Befehlszeile in ein Git-Repository konvertieren oder ein bereits hochgeladenes Git-Repository in Ihr eigenes kopieren.

Wenn Sie ein Repository erstellen, erhalten Sie normalerweise zwei Optionen – Öffentlich und Privat. Das öffentliche Repository ist dasjenige, das von anderen Entwicklern mit Git eingesehen werden kann, und das private Repository hingegen ist eines, das nur von wenigen Personen eingesehen werden kann.

Verzweigung

Neben Repository-Erstellung befindet sich Verzweigung. In einem Unternehmen wie Appinventiv, in dem zu einem bestimmten Zeitpunkt über 15 – 20 Entwickler an einem Projekt arbeiten, ist es nicht ungewöhnlich, dass die Entwickler denselben Quellcode teilen und daran arbeiten. Was passiert ist, dass einige Entwickler damit beschäftigt sind, Probleme zu beheben, während andere möglicherweise einige Funktionen implementieren.

In einer solchen Situation brauchen wir ein System, das es einfach macht, verschiedene Codeversionen in derselben Codebasis zu handhaben.

Hier kommt Gitflow ins Spiel. Gitflow ist ein Framework, das zum systematischen und effizienten Verzweigen verwendet wird.

Bevor wir mit der Funktionsweise des Branching-Prozesses auf Gitflow fortfahren, möchte ich das Konzept anhand eines Beispiels erläutern.

Angenommen, Ihr Team besteht aus 5 Entwicklern, die an der Entwicklung einer Instagram-ähnlichen App arbeiten. Jetzt werden die einzelnen App-Funktionen wie Feed und Benachrichtigungen als Modul 1, Modul 2 usw. bezeichnet. Nun sind diese verschiedenen Module Entwicklungszweige, die nach der Bearbeitung mit dem übergeordneten Zweig oder Master zusammengeführt werden.

In dem Moment, in dem ein Entwickler einen Branch hinzufügt, erstellt er eine unabhängige Entwicklungslinie, die seine Arbeit von der seiner Teammitglieder isoliert. Die verschiedenen Zweige werden dann mit dem übergeordneten Zweig zusammengeführt.

Verzweigung ist die Methode, mit der die Teammitglieder erkennen können, welche Änderungen sie erwarten sollten, und was das Zurückverfolgen einfach macht.

In unseren Projekten behalten wir normalerweise diese Äste bei –

• Master-Zweig
• Entwicklungszweig
• Feature-Zweig
• Zweig freigeben
• Hotfixes und Fehlerbehebungen

Verpflichten

Die Änderungen, die ein Entwickler in der einzelnen Datei vornimmt, werden als Commit bezeichnet. Die Änderungen oder der Commit werden im lokalen Repository und nicht auf dem Server hinzugefügt. Als nächstes folgen unsere Entwickler der Gewohnheit, eine Commit-Nachricht zu schreiben, in der die Beschreibung des Commit (in der Datei vorgenommene Änderungen) veröffentlicht werden, sodass andere Entwickler auch die Details der in der Datei vorgenommenen Änderungen kennen.

Drücken

Wenn Sie im lokalen Git-Repository committen, werden die Änderungen als Nächstes an den Server gesendet, was als Push bezeichnet wird .

Es ist ziemlich einfach, den Commit-Verlauf auf den Server zu übertragen, wenn Sie der einzige sind, der an einer Datei arbeitet, aber falls auch andere Entwickler an dem Prozess beteiligt sind, müssen Sie die Änderungen abrufen, bevor Sie Ihren Satz übertragen können Commit zu Git.

Als Nächstes werden wir untersuchen, was im Schritt Pull Change getan wird.

Pull-Anfrage

Wenn mehr als ein Entwickler an derselben Datei arbeitet, kann es vorkommen, dass ein Commit vom anderen Entwickler auf den Server übertragen wird, bevor Sie ihn übertragen. Und wenn das passiert, kommt es zu Konflikten (dazu später mehr).

Um zu vermeiden, dass dieselbe Codebasis zweimal auf den Server hochgeladen wird, ziehen Entwickler zuerst die Änderungen aus dem Repository und stellen sicher, dass die Codes unterschiedlich sind. Wenn nun zwei oder mehr Entwickler an derselben Datei arbeiten und ihr Commit auf den Server pushen, erscheint im Allgemeinen die Option „Merge“.

Lassen Sie uns als nächstes über Merge sprechen.

Verschmelzen

Merge ist der Schritt, bei dem Entwickler alle Branches zuerst miteinander und dann mit dem Master- oder Parent-Branch verbinden.

Jedes Mal, wenn ein Deliver einen Push-Befehl eingibt, erhält er eine Merge-Option, die ihn dann nach dem Branch fragt, mit dem er den Commit zusammenführen möchte.

In der Merge-Phase kommt es jetzt sehr häufig zu Konflikten. Konflikte treten normalerweise auf, wenn die beiden Zweige, die Sie zusammenführen möchten, im selben Teil in derselben Datei geändert wurden. Was hier passiert, ist, dass Git nicht herausfinden kann, welche Version verwendet werden soll.

Wenn dieses Konfliktproblem auftritt, bietet Git zwei Lösungen an – Automatisch und Manuell.

Wie der Name schon sagt, findet Git in einem das Problem selbst heraus und in letzterem müssen die Entwickler es manuell tun. Bei Appinventiv konzentrieren wir uns auf die manuelle Lösung von Konflikten, da selbst die winzigen Chancen des Auftretens von Fehlern eliminiert werden.

Während wir Git für die Versionskontrolle unseres App-Entwicklungsprozesses verwenden, geschieht gleichzeitig die Problemverfolgung.

Da wir ein großer Anhänger von Agile sind und Agile für unseren Entwicklungsprozess für mobile Apps vertrauen , wissen wir, wie wichtig es ist, mehrere Entwicklungsprozesse gleichzeitig zu handhaben. Und mit der Problemverfolgungsfunktion wird es für Tester viel einfacher, den Code, der geschrieben und auf den Git-Server übertragen wurde, in Echtzeit im Auge zu behalten.

Wir verwenden das ZenHub-Board, um den Workflow in jedem Repository zu überwachen. Das Board ermöglicht es uns, die Priorität der vorgeschlagenen Änderung zu verfolgen und den Entwicklern zu helfen, ihre Kommentare im Board in Echtzeit zu aktualisieren.