ZFX + Developia

Hallo liebe Community,

DVC ist ein sehr neues Thema für mich und über die vergangenen Tage hinweg, habe ich mich in in Git, BitBucket & SourceTree eingelesen.
Seit heute morgen habe ich auch ein funktionierendes Repository, das ohne Probleme mit Unity arbeitet. Auch meine Kollegen können problemlos Commits pullen und in ihr Unity-Projekt integrieren.

Nun zu meiner Frage: Man muss ja, wenn man als Team ein Repo auf Bitbucket erstellt, das ganze in ein "Projekt" packen. Das Spiel, welches wir aktuell entwickeln soll auf mehreren Plattformen erscheinen (hauptsächlich Steam/Windows & Android). Nun frage ich mich ob es eine "standardisierte" oder "allgemein anerkannte" Projekt-Strukturierung in einem solchen Fall.

Beispielsweise: Für jedes Build-Target ein Projekt.
ein Repository im Projekt.
ein Branch im Repository im Projekt (also ein Master-Branch und von da ausgehend Branches für verschiedene Targets)

Die letzte Option schien mir im ersten Moment am sinnvollsten, aber ich würde gerne die Meinung von Veteranen des Game Developments oder Leuten, die vor einer ähnlichen Situation standen, interessieren. Natürlich können alle anderen auch ihre Meinung zu dem Thema beitragen.

Viele liebe Grüße

Hex | Simon

[EDIT: Wir benutzen nicht Unity Cloud Build]

Ich fahre bei solchen Sachen gern erstmal mal die Minimallösung und schau dann was sich optimieren lässt. In deinem Fall wäre das ein Projekt, ein Repository und ein Branch, wenn ich dich richtig verstanden habt. So Geschichten wie ein vernünftiges Branchingmodell müssen imho aus dem Bedarf heraus und erfahrungsgetrieben entstehen, da wild irgendwas im Vorfeld zu definieren führt meistens eher zu Scherereien und Frustration. Ist ja auch alles nicht in Stein gemeißelt und lässt sich jederzeit anpassen... :)

Sehr empfehlen kann ich an der Stelle das Workflow-Tutorial von Atlassian.

Persönlich arbeite ich ganz gerne "feature-orientiert". Das heißt Features oder Bugfixes die umzusetzen sind, werden zu einem Branch auf dem separat entwickelt wird und am Ende wird gemerget. Das skaliert meiner Erfahrung nach für kleinere Projekte ausreichend gut, geht rein organisatorisch und technisch gut mit den meisten Ticketssystemen zusammen und inzwischen gibt's ja praktisch in allen Git-"Oberflächen" sowas wie Merge/Pull-Requests mit denen sich der Branch wieder super easy reintegrieren lässt. Achja, als Chefentwickler/Architekt/Projektleitung kannst du in dem Moment auch nochmal über die Änderungen drüber gucken und ggf. steuern in welcher Reihenfolge der Kram integriert werden soll. Bisschen aufpassen musst du dabei, das die Features überschaubar und abgeschlossen sind. Sonst hast du ganz schnell so Dauerläufer-Branches und mergest dann doch wieder nur hin und her. Aber in dem Sinne fördert es auch vernünftiges Projektmanagement. Achja, und ich hab natürlich keine Ahnung wie gut das mit Unity zusammen geht, ist ja rein technisch und auch organisatorisch wie Artefakte verwaltet werden etc. sicher doch bisschen was Anderes als klassische Softwareentwicklung. :)

Branches solltest Du für unterschiedliche Entwicklungsaufträge und oder Entwicklungsphasen verwenden. Wenn Du trunk-based arbeitest (bei Spielen wahrscheinlich gar nicht schlecht, siehe auch http://paulhammant.com/2013/04/05/what- ... evelopment https://dzone.com/articles/googles-scaled-trunk-based) würde man Branches vor allem für die lokale Entwicklung erzeugen und Tags anlegen, wenn ein Release erfolgt. Ein Commit sollte immer zu einer kompilierbaren Version im Trunk führen.

Ich würde Dir empfehlen pro build-target ein Projekt innerhalb eines Wurzelprojekts anzulegen. Das eigentliche Spiel wird dann in einem eigenen von der Zielplattform losgelösten Projekt innerhalb der Hierarchie entwickelt. Ich gehe davon aus, dass auch Unity3D selbst so entwickelt wird. Mit Gradle (das Buildsystem, das Unity3D verwendet) lässt sich diese Projektstruktur sehr gut abbilden.

Noch als Hinweis, damit ihr nicht aus Versehen generierte Artefakte versioniert: https://www.gitignore.io/ => Unity + weitere IDEs und Tools eingeben.