Dies ist bei weitem die einfachste Verbesserung, die Sie an Ihrem Arbeitsablauf vornehmen können, und doch ist es diejenige, mit der einige Entwickler am meisten zu kämpfen haben. Wenn Sie mit anderen Projektmanagement-Tools arbeiten, haben Sie die Arbeit wahrscheinlich bereits in kleine, überschaubare Aufgaben aufgeteilt. Verpflichtungserklärungen sollten genau so behandelt werden.

Ein einzelner Commit sollte sich nur auf eine Aufgabe oder ein Ticket beziehen, es sei denn, eine einzige Codezeile behebt auf magische Weise mehrere Fehler. Wenn Sie an einer größeren Funktion arbeiten, unterteilen Sie sie in kleinere Aufgaben und machen Sie Commits für jede.

Der größte Vorteil der Verwendung kleinerer Commits ist, dass Sie unerwünschte Änderungen viel leichter erkennen und rückgängig machen können, wenn etwas schief geht.

Commit-Nachrichten beschreiben den Verlauf Ihres Projekts. Schließlich ist es viel einfacher, die Änderung zu finden, die Ihrem Spiel Highscore-Tabellen hinzugefügt hat, wenn die Commit-Meldung lautet "Highscore-Tabellen zum Menü hinzugefügt" und nicht "Wetten, dass Sie meine Punktzahl an diesen neuen Tischen nicht übertreffen können!"

Wenn Sie mit einem Task-Ticketing-System wie Jira oder GitLab arbeiten, ist es sogar noch besser, eine Ticketnummer in Ihre Übergabe einzubinden. Viele Systeme können so eingerichtet werden, dass sie mit Smart Commits zusammenarbeiten, so dass Sie in Ihrer Commit-Nachricht auf Tickets verweisen und deren Status ändern können.

Ein Commit mit dem Inhalt "JRA-123 #close #comment task completed" würde beispielsweise das Jira-Ticket JRA-123 auf "closed" setzen und den Kommentar "task completed" auf dem Ticket hinterlassen.

Weitere Informationen zum Einrichten dieses Workflows finden Sie in der Dokumentation in Jira oder im Pivotal Tracker-Dienst in GitLab.

Das einzige Mal, dass "commit -a" (der Git-Befehl für "alle Änderungen übertragen") oder eines seiner Gegenstücke verwendet werden sollte, ist bei der ersten Übertragung 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, die Sie in das Projektarchiv übertragen, in Zusammenhang stehen. 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, z. B. Szenen, Prefabs oder Sprite Atlases, obwohl Sie gar nicht beabsichtigt haben, diese zu ändern.

Wenn Sie zum Beispiel versehentlich eine Änderung an einer Szene vornehmen, an der jemand anderes arbeitet, kann das demjenigen Kopfzerbrechen bereiten, wenn er seine Änderungen vornehmen will und sieht, dass er Ihre Änderungen zuerst zusammenführen muss.

Dies ist einer der häufigsten Fehler, die Menschen machen, die neu in der Versionskontrolle sind. Es ist wichtig zu verstehen, dass Sie nur Ihre eigenen Änderungen an das Projekt übertragen sollten. Weitere Informationen finden Sie in diesem Blogbeitrag über die Beschleunigung Ihres Arbeitsablaufs.

Ziehen Sie, so oft es sinnvoll ist, die letzten Änderungen aus dem Projektarchiv in Ihre Arbeitskopie. Es ist keine gute Idee, isoliert zu arbeiten, da dies nur die Wahrscheinlichkeit von Konflikten bei der Zusammenführung erhöht. In der obigen Tabelle finden Sie einen Überblick über den typischen täglichen Arbeitsablauf für jedes System.

Kunststoff-SCM-Workflows sind etwas anders, da Sie in zentralen, verteilten oder standortübergreifenden Konfigurationen arbeiten können.

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

Betrachten Sie das folgende Beispiel:

• Zwei Teams
• Jedes Team hat einen eigenen Server vor Ort
• Teammitglieder checken lokal oder verteilt an jedem Standort ein, profitieren aber von der Geschwindigkeit eines nahe gelegenen Servers vor Ort
• Server schieben und ziehen sich gegenseitig, um ganz oder teilweise synchron zu bleiben

Unabhängig davon, für welches VCS sich Ihr Team entscheidet, stellen Sie sicher, dass jeder damit vertraut ist und die ihm zur Verfügung stehenden Werkzeuge versteht.

Wenn Sie mit Git arbeiten, muss nicht jeder denselben GUI-Client verwenden. Aber machen Sie es zu einer Priorität, dass sich jeder mit dem Arbeitsablauf Commit > Pull > Push wohl fühlt. Mit anderen Worten: Sie sollten in der Lage sein, nur die Dateien zu übertragen, die sie benötigen.

Wenn Sie mit Plastic SCM arbeiten, sollten Sie die Künstler in Ihrem Team ermutigen, sich mit Gluon vertraut zu machen, einer benutzerfreundlichen GUI zur Vereinfachung ihrer Arbeitsabläufe. Mit Gluon können Sie sich für die Dateien entscheiden, die Sie bearbeiten möchten, und müssen nicht das gesamte Projekt herunterladen und verwalten. Außerdem können Sie Dateien sperren, so dass andere nicht mehr daran arbeiten können. Wenn Sie fertig sind, übermitteln Sie die Dateien wieder an das Repository und schalten Sie sie bei Bedarf wieder frei.

Wenn Sie an einem langjährigen Projekt mit mehreren Versionszyklen arbeiten, ist die Verzweigung von Funktionen für Ihren Arbeitsablauf von großem Nutzen. Oft arbeiten Teams aus demselben Zweig eines Repo, der wahrscheinlich trunk, master oder main heißt.

Auf diese Weise bewegt sich Ihr gesamtes Projekt auf der gleichen Zeitachse. Es kann jedoch sinnvoll sein, die Arbeit in mehrere Zweige aufzuteilen, um effektiver im Team zusammenarbeiten zu können.

In Git gibt es einen speziellen Arbeitsablauf namens Git Flow, der sich auf die Verwendung verschiedener Zweige für Funktionen, Fehlerbehebungen und Veröffentlichungen konzentriert.

Wenn also ein Entwickler in einem isolierten Zweig mit der Arbeit an einer neuen Funktion beginnt, wird dieser Zweig wieder mit dem Hauptzweig zusammengeführt, sobald er fertig ist. In der Zwischenzeit kann ein anderer Teammitglied ein Hotfix für die vorherige Version durchführen oder einen Fehler beheben und eine neue Version sicher veröffentlichen, ohne die noch in der Entwicklung befindlichen Funktionen zu berücksichtigen.

Plastic SCM bietet auch Aufgabenverzweigungen. Bei diesem Muster erstellen Sie für jede Aufgabe, die Sie verfolgen, einen neuen Zweig. In Git Flow verwenden wir Feature-Zweige, um komplette, manchmal umfangreiche Features zu entwickeln. Aufgabenzweige in Plastic SCM sind für eine kurze Lebensdauer gedacht. Wenn die Implementierung einer Aufgabe mehr als eine Handvoll Commits erfordert, besteht die Chance, dass sie in kleinere Aufgaben aufgeteilt werden kann.

Perforce Helix Core verwendet ein System namens Streams , um diese Art von Arbeitsablauf zu erleichtern. Wenn Sie ein Depot anlegen, in dem Sie arbeiten wollen, müssen Sie es als Stream-Depot-Typ einrichten. Anschließend können Sie in der Ansicht Stream Graph neue Streams erstellen. Jeder Stream (außer dem Mainline-Stream) muss einen übergeordneten Stream haben, damit Änderungen stromaufwärts zurückkopiert werden können.

Es gibt verschiedene Arten von Strömen für unterschiedliche Zwecke. Wenn Sie auf Ihrer lokalen Workstation zwischen Streams wechseln oder Änderungen zurückkopieren, werden nur die Metadaten der geänderten Dateien zusammengeführt, sodass der Kontextwechsel schneller vonstatten geht.

Wenn Sie die Arbeit an einem Funktionszweig abgeschlossen haben, ist es eine gute Praxis, Pull Requests zu verwenden, um Ihre Änderungen wieder in den Hauptstrom des Repositorys zu bringen. Pull Requests werden von den Entwicklern der Funktion oder Aufgabe erstellt. Normalerweise ist ein erfahrener Entwickler oder DevOps dafür verantwortlich, die Änderungen zu überprüfen, bevor sie in die Mainline übernommen werden.

Sowohl Plastic SCM als auch Perforce verfügen über automatisierte Tools, die das Zusammenführen von Zweigen in die Mainline unterstützen. Plastic SCM macht dies mit Hilfe von Mergebot, das automatisch Zweige eines Repos zusammenführt, sobald sie überprüft wurden und die Validierung bestanden haben. Perforce verfügt über eine zusätzliche Plattform, Helix Swarm, die für die Verwaltung von Code-Reviews verwendet wird und auch mit automatisierten Tests eingerichtet werden kann.

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

Bei der Arbeit mit einem Team ist es wichtig, dass eine klare Kommunikation im Vordergrund steht. Als Gruppe müssen Sie sich auf Ihre Richtlinien einigen: wie Sie Ihr Projekt strukturieren, welches Versionskontrollsystem Sie verwenden und wie Ihr Arbeitsablauf in diesem System aussehen soll.

Wenn Sie dann andere Tools wie Jira, GitLab, Build-Tools oder automatisierte Tests integrieren, kommt die Arbeit, die Sie bereits bei der Strukturierung Ihres Projekts und Arbeitsablaufs geleistet haben, voll zum Tragen.