Bewährte Verfahren für die Versionskontrolle

Dies ist bei weitem die einfachste Verbesserung, die Sie an Ihrem Workflow vornehmen können, und doch ist es die, mit der einige Entwickler am meisten kämpfen. Wenn Sie mit anderen Projektmanagement-Tools arbeiten, ist es wahrscheinlich, dass Sie die Arbeit bereits in kleine, überschaubare Aufgaben unterteilt haben. Commits sollten genau gleich behandelt werden.

Ein einzelner Commit sollte nur mit einer Aufgabe oder einem Ticket in Verbindung stehen, es sei denn, eine einzelne Codezeile behebt magisch mehrere Fehler. Wenn Sie an einem größeren Feature arbeiten, zerlegen Sie es in kleinere Aufgaben und machen Sie für jede einen Commit.

Der größte Vorteil kleinerer Commits ist, dass Sie, wenn etwas schiefgeht, unerwünschte Änderungen viel einfacher erkennen und zurücksetzen können.

Commit-Nachrichten beschreiben die Geschichte Ihres Projekts. Schließlich ist es viel einfacher, die Änderung zu finden, die die Highscore-Tabellen zu Ihrem Spiel hinzugefügt hat, wenn die Commit-Nachricht "Highscore-Tabellen zum Menü hinzugefügt" lautet, anstatt "Wette, du kannst meinen Punktestand auf diesen neuen Tabellen nicht schlagen!"

Wenn Sie mit einem Ticket-System wie Jira oder GitLab arbeiten, ist es sogar besser, eine Ticketnummer in Ihren Commit aufzunehmen. Viele Systeme können so eingerichtet werden, dass sie mit intelligenten Commits zusammenarbeiten, sodass Sie tatsächlich Tickets referenzieren und deren Status aus Ihrer Commit-Nachricht ändern können.

Ein Commit, der "JRA-123 #close #comment Aufgabe abgeschlossen" lautet, würde das Jira-Ticket JRA-123 auf geschlossen setzen und den Kommentar "Aufgabe abgeschlossen" auf dem Ticket hinterlassen.

Für weitere Informationen zur Einrichtung dieses Workflows siehe die Dokumentation in Jira oder den Pivotal Tracker-Dienst in GitLab.

Die einzige Zeit, in der "commit -a" (der Git-Befehl für "alle Änderungen committen") oder einer seiner Gegenstücke verwendet werden sollte, ist beim ersten Commit eines Projekts. Normalerweise ist dies der Fall, wenn die einzigen Dateien im Projekt README.md sind.

Ein Commit sollte nur Dateien enthalten, die mit der Änderung in Verbindung stehen, die Sie im Repo committen. Sie sollten besonders vorsichtig sein, wenn Sie mit Unity-Projekten arbeiten, da einige Änderungen dazu führen können, dass mehrere Dateien als geändert markiert werden, wie Szenen, Prefabs oder Sprite-Atlanten, auch wenn Sie nicht beabsichtigt haben, Änderungen daran vorzunehmen.

Wenn Sie versehentlich eine Änderung an einer Szene committen, an der jemand anderes arbeitet, kann dies für ihn Kopfschmerzen verursachen, wenn er seine Änderungen committen möchte und sieht, dass er zuerst Ihre Änderungen zusammenführen muss.

Dies ist einer der häufigsten Fehler, die Menschen machen, die neu im Bereich der Versionskontrolle sind. Es ist wichtig zu verstehen, dass Sie nur Ihre eigenen Änderungen am Projekt committen sollten. Um mehr zu erfahren, lesen Sie diesen Blogbeitrag, wie Sie Ihren Workflow beschleunigen können.

So oft es sinnvoll ist, ziehen Sie die neuesten Änderungen aus dem Repo in Ihre Arbeitskopie. Es ist keine gute Idee, isoliert zu arbeiten, da dies nur die Wahrscheinlichkeit von Merge-Konflikten erhöht. Siehe die obige Tabelle, um eine Vorstellung von einem typischen täglichen Arbeitsablauf für jedes System zu bekommen.

Plastic SCM Arbeitsabläufe sind ein wenig anders, da Sie in zentralisierten, verteilten oder Multisite-Konfigurationen arbeiten können.

Multisite-Konfigurationen können ziemlich einzigartig sein, wobei jeder Benutzer entweder in einem zentralisierten oder verteilten Arbeitsablauf arbeitet.

Betrachten Sie das folgende Beispiel:

• Zwei Teams
• Jedes Team hat einen lokalen Server
• Teammitglieder checken lokal oder verteilt an jedem Standort ein, profitieren jedoch von der Geschwindigkeit eines nahen lokalen Servers.
• Server pushen und ziehen zwischen einander, um vollständig oder teilweise synchron zu bleiben.

Unabhängig von dem VCS, mit dem Ihr Team arbeiten möchte, stellen Sie sicher, dass jeder sich damit wohlfühlt und die Werkzeuge versteht, die ihm zur Verfügung stehen.

Wenn Sie mit Git arbeiten, muss nicht jeder denselben GUI-Client verwenden. Aber machen Sie es zur Priorität, sicherzustellen, dass sich jeder mit dem commit > pull > push Arbeitsablauf wohlfühlt. Mit anderen Worten, sie sollten das Wissen haben, nur die Dateien zu committen, die sie benötigen.

Wenn Sie mit Plastic SCM arbeiten, ermutigen Sie die Künstler in Ihrem Team, sich an Gluon zu gewöhnen, eine benutzerfreundliche GUI zur Vereinfachung ihres Arbeitsablaufs. Gluon ermöglicht es Ihnen, die Dateien auszuwählen, an denen Sie arbeiten möchten, wodurch die Notwendigkeit entfällt, das gesamte Projekt herunterzuladen und zu verwalten. Es ermöglicht Ihnen auch, Dateien zu sperren, was verhindert, dass andere an ihnen arbeiten. Sobald Sie fertig sind, reichen Sie die Dateien wieder im Repository ein und entsperren Sie sie nach Bedarf.

Bei der Arbeit an einem langfristigen Projekt mit mehreren Release-Zyklen ist das Feature-Branching für Ihren Workflow sehr vorteilhaft. Oft arbeiten Teams aus demselben Branch eines Repos, der wahrscheinlich trunk, master oder main genannt wird.

Wenn Sie dies tun, bewegt sich Ihr gesamtes Projekt entlang derselben Zeitachse. Es kann jedoch nützlich sein, die Arbeit in mehrere Branches aufzuteilen, um effektiver als Team zusammenzuarbeiten.

In Git konzentriert sich ein spezifischer Workflow namens Git Flow darauf, verschiedene Branches für Features, Bugfixes und Releases zu verwenden.

Wenn ein Entwickler also an einem neuen Feature in einem isolierten Branch arbeitet, wird es zurück in den Hauptbranch zusammengeführt, sobald er fertig ist. In der Zwischenzeit kann ein anderer Teamkollege einen Hotfix für das vorherige Release durchführen oder einen Bug beheben und eine neue Version sicher veröffentlichen, ohne Funktionen einzuschließen, die sich noch in der Entwicklung befinden.

Plastic SCM bietet auch Aufgaben-Branches an. Für dieses Muster erstellen Sie einen neuen Branch für jede Aufgabe, die Sie verfolgen. Während wir in Git Flow Feature-Branches verwenden, um vollständige, manchmal große, Features zu entwickeln. Aufgaben-Branches in Plastic SCM sind für eine kurze Lebensdauer gedacht. Wenn eine Aufgabe mehr als eine Handvoll Commits zur Implementierung benötigt, ist die Wahrscheinlichkeit hoch, dass sie in kleinere Aufgaben aufgeteilt werden kann.

Perforce Helix Core verwendet ein System namens Streams, um diesen Workflow-Stil zu erleichtern. Beim Erstellen eines Depots, in dem Sie arbeiten möchten, müssen Sie es als Stream-Depottyp einrichten. Dann können Sie die Stream Graph-Ansicht verwenden, um neue Streams zu erstellen. Jeder Stream (außer dem Hauptstream) benötigt einen übergeordneten Stream, damit Änderungen wieder nach oben kopiert werden können.

Es gibt verschiedene Arten von Streams für unterschiedliche Zwecke. Wenn Sie zwischen Streams auf Ihrem lokalen Arbeitsplatz wechseln oder Änderungen wieder nach oben kopieren, werden nur die Metadaten für geänderte Dateien zusammengeführt, was den Kontextwechsel schneller macht.

Sobald Sie die Arbeit an einem Feature-Branch abgeschlossen haben, ist es gute Praxis, Pull-Requests zu verwenden, um Ihre Änderungen wieder in den Hauptstream des Repos zu bringen. Pull-Requests werden von den Entwicklern des Features oder der Aufgabe erstellt. In der Regel liegt es in der Verantwortung eines Senior-Entwicklers oder DevOps, die Änderungen zu überprüfen, bevor sie in den Hauptstream aufgenommen werden.

Plastic SCM und Perforce verfügen beide über automatisierte Tools, die helfen, Branches wieder in den Hauptstream zu integrieren. Plastic SCM macht dies mit Hilfe von Mergebot, das automatisch Branches eines Repos zusammenführt, sobald sie überprüft wurden und die Validierung bestanden haben. Perforce hat eine zusätzliche Plattform, Helix Swarm, die zur Verwaltung von Codeüberprüfungen verwendet wird und ebenfalls mit automatisierten Tests eingerichtet werden kann.

Selbst wenn Sie an einem Solo-Projekt arbeiten, können die Prinzipien der Organisation und Versionskontrolle sehr nützlich sein.

Bei der Arbeit im Team ist es entscheidend, klare Kommunikation zu priorisieren. Als Gruppe müssen Sie sich auf Ihre Richtlinien einigen: wie Sie Ihr Projekt strukturieren, welches Versionskontrollsystem Sie verwenden und wie Ihr Workflow in diesem System aussehen sollte.

Auf diese Weise wird die Arbeit, die Sie bereits bei der Strukturierung Ihres Projekts und Workflows geleistet haben, von Bedeutung, wenn Sie beginnen, andere Tools wie Jira, GitLab, Build-Tools oder automatisierte Tests zu integrieren.