Als Programmierer ist man es gewohnt: Mithilfe von Git oder anderen Version-Control-Systemen können ganze Projekte einfach mit Team-Mitgliedern geteilt werden. Jeder kann seinen Code hinzufügen, verändern und wieder zur Verfügung stellen. Man kann neue Teile in Branches auslagern und wieder zusammenführen. Man hat Zugriff auf alte Versionen und kann die verschiedene Stati vergleichen. Einmal daran gewöhnt, kann man sich nur schwer von diesem Luxus verabschieden.
Videoschnitt, Animation und Motion Graphics funktionieren anders. Auch wenn Filmschnitt oder Animationen oftmals riesigen Aufwand bedeuten, so ist es bisher nicht möglich, dass zum Beispiel zwei Motion Designer gleichzeitig und effizient an einem After-Effects-Projekt arbeiten. Der Weg war meist: Arbeitspakete aufteilen und sich möglichst wenig in die Quere kommen. Man konnte zwar After-Effects-Projekte importieren, das war allerdings more pain than gain. Das gesamte Projekt mit allen Verlinkungen, Assets etc. wurde importiert, unabhängig davon, ob gemeinsame Assets verwendet werden. Mehrmaliges Importieren von Projekten führte zu einem wilden Potpourri an Files, Kompositionen, Verlinkungen, die nur schwer nachvollziehbar geschweige denn produktiv waren.
Und Version Control sah bisher in vielen Fällen so aus:
Es geht auch natürlich auch schlimmer.
Git für After Effects?
Wir verwenden seit Jahren Git (und davor SVN) für unsere Programmierprojekte. Und eigentlich ist es Git ja egal, welche Files im Repository sind, oder?
Nicht ganz. Für Design- und/oder Videoprojekte gibt es zwei erhebliche Nachteile, wenn man Git verwenden will:
- Geschwindigkeit
Git ist auf textbasierte Files ausgerichtet. Große Bilder oder gar Videofiles, die im Raw-Format gerne auch mal das ein oder andere Gigabyte auf die Waage bringen, können das System sehr langsam werden lassen. Es gibt jedoch Extensions (z.B. https://git-lfs.github.com/), mit denen große Dateien als Referenzen gespeichert werden können. - Binärdateien
Ein weitaus größeres Problem ist, dass After-Effects-Files Binärdateien sind. Eine zugefügte Komposition führt zu einer Änderung des gesamten Files und Git ersetzt es. Damit wird das Konflikt-Management zwar einfach (nimm das neue File oder behalte das alte), bestimmte Kompositionen von einem Teammitglied oder einem anderen Branch zu importieren, ohne die aktuellen Änderungen am lokalen File zu verlieren, geht allerdings nicht.
Somit wird Git für After Effects zu einer mittelmäßigen Versionierung, für Kollaboration eignet es sich nicht. Was tun also, wenn eine Zusammenarbeit mehrerer KollegInnen notwendig ist?
Adobe Team Projects
Adobe hat mit der Cloud bereits den Weg zu einfacherer Kollaboration eingeschlagen: Assets können über Bibliotheken oder über geteilte Ordner und Dateien der Creative Cloud geteilt werden. Für die Videosparte (Prelude, Premiere Pro, After Effects) gibt es seit kurzem die Team Projects (in der Beta-Phase), die nun tatsächliche Kollaboration an Video-Projekten liefern sollen. Wir haben uns das anhand eines After-Effects-Projektes etwas näher angesehen und wollen euch unsere wichtigsten Erkenntnisse natürlich nicht vorenthalten. Da es sich im Moment um eine Beta-Version der Team-Projects handelt, kann es sich bei der ein oder anderen Seltsamkeit natürlich um einen Bug handeln, der bis zum finalen Release noch ausgebessert wird.
Ein Projektfile im herkömmlichen Sinne gibt es nicht. Es ist so ein bisschen „unsichtbar“.
Benennung
Der Name des Teamprojektes bleibt wie er ist, also sei er weise gewählt. Außerdem ist jedes Team Project in jeder (Team-Projects-)App auswählbar, ohne dass man sieht ob das nun ein After-Effects-, oder doch ein Premiere-Pro-File ist. Es hat sich also als sinnvoll herausgestellt, die Art des Files in den Team-Projekt-Namen zu integrieren (zb. einfach als Pseudo-Extension my-awesome-animation.aep)
Sicherungskopien
Wenn ein Team-Projekt angelegt wird, wird kein aep-File erstellt, das man sich irgendwo hinkopieren und mitnehmen könnte. Gut versteckt im Application-Support- (Mac) oder AppData-Ordner (Windows) werden die Dateien und Änderungen zwar lokal gespeichert, ein Projektfile im herkömmlichen Sinne gibt es dort aber auch nicht. Es ist so ein bisschen „unsichtbar“. Wem das (wie mir) ein bisschen suspekt ist, kann das Projekt über „Edit > Team Project > Convert Team Project to Project“ in ein „normales“ File exportieren lassen. Achtung: Ein normales Projekt wieder in ein Team-Projekt umzuwandeln klappt nicht. Die somit erstellte Sicherungskopie ist also nur ein Notrad, kein richtiges Reserverad.
Version Control
Wenn man Änderungen freigibt, kann man diese kommentieren. Das ist hilfreich, wenn man eine oder mehrere Kompositionen von einem früheren Zeitpunkt wiederherstellen möchte. Im Media Browser kann man sich anhand einer Zeitleiste alle freigegebenen Änderungen (inkl. der Kommentare) durchsehen und sich die Kompositionen oder Assets, die man braucht, in seine aktuelle, lokale Projektstruktur ziehen.
Achtung: Das Kopieren einzelner Kompositionen kopiert zusätzlich alle in dieser Komposition verwendeten Assets. Deshalb ist es erstens sinnvoll, einen neuen Ordner für die importierten Kompositionen anzulegen und zweitens – bei aufwendigen, großen Kompositionen – eher mit Vorsicht zu genießen, da man sich so relativ schnell einen Urwald aus doppelt und dreifach vorhandenen Kompositionen und Assets züchtet. Ein praktikabler Weg, falls man eine Animation vergeigt hat, ist: Die funktionierende, alte Komposition in einen Ordner (zB. „/v2-tmp/„) kopieren, die Ebenen, Keyframes, etc, die man braucht, in die aktuelle, “lokale” Komposition kopieren und dann den Ordner wieder löschen. Somit werden für das gesamte Projekt dieselben Assets verwendet und alles bleibt sauber.
Version Control im Team Project
Zuverlässigkeit
Es handelt sich um Beta-Software, Bugs sind also verzeihbar. Grobe Probleme hatten wir bei unseren Team-Projekten bisher nicht, nur hin und wieder haben sich Ankerpunkte verschoben, oder die Verbindung zur Cloud hat nicht geklappt. Ansonsten waren wir ziemlich beeindruckt, wie schnell und stabil es läuft.
Branches
Wir sind Git gewohnt – sind die Team-Projects vergleichbar? Wir ertappen uns oft dabei, beim Klicken auf „Änderungen herunterladen“ zu sagen: „Ich pulle jetzt“, oder nachdem ich eine Änderung freigegeben habe: „Hab ich gerade gepusht“. Das funktioniert auch so, wie man es erwartet. Was uns allerdings doch etwas abgeht, sind Branches. Es kann vorkommen, dass ich eine Animation noch anders probieren will. Sie sieht zwar schon gut aus, aber vielleicht, ja, vielleicht könnte sie noch besser aussehen, wenn ich sie völlig anderes angehe. Dafür wäre ein Branch super. Ich würde weder meine bisherige eh-schon-schöne Animation verändern müssen, noch müsste ich mir für jeden Versuch eine neue Kopie der Komposition anlegen (bei verschachtelten Kompositionen gar nicht so schnell gemacht). Schnell mal ein neues File anlegen geht ja nicht, da es bei Team Projects keine „Files“ gibt.
Fazit
Nach dem ersten After Effects Team-Project sind wir sehr zufrieden. Es ist natürlich hilfreich, wenn alle Teammitglieder im selben Raum / Büro sitzen, da so Konflikte einfach gelöst und Verwirrungen generell schnell abgefangen werden können. Es wirkt zwar noch nicht völlig ausgereift, allerdings läuft es bisher so stabil, dass wir an unserem kleinen Projekt sicherlich schneller und besser gemeinsam arbeiten konnten, als dies früher der Fall war. Wir sind jedenfalls gespannt, was sich bis zum offiziellen Release noch tun wird und wie die Reise in die kollaborative Zukunft im Bereich Video und Motion Graphics weitergeht.
Genauere Infos über die aktuellen Features und wie man sie benutzt gibt’s hier: https://helpx.adobe.com/beta/team-projects/using-team-projects.html
