Einfache Möglichkeit, Nicht-Programmierer (z. B. Designer) in die Versionskontrolle einzubeziehen?


13

Was sind einige wichtige Möglichkeiten, um Ihr Team in die Verwendung der Versionskontrolle während der Entwicklung, der Webentwicklung oder auf andere Weise einzubeziehen?

Ich lehne es ab, ohne es zu arbeiten, was bedeutet, dass jeder, der an dem Projekt beteiligt ist, es auch benutzen muss. Es ist nur eine gute Übung.

GUIs wie Tower haben geholfen, aber das Konzept davon stößt entweder auf Ärger („Nicht mein Job!“ - Einstellung), Schüchternheit oder einfach nur darauf, es nicht zu verwenden (stattdessen FTP zu verwenden und die Versionskontrolle zu umgehen, z. B. für Entwickler oder Bereitstellung) ).

Edit: Ich hätte ein wenig klarstellen sollen, dass ich nicht nur Bilder / PSDs meine.


11
Machen Sie es einfach zu bedienen ...

1
Ich finde, dass Git ziemlich einfach ist, wenn man ein paar Tage damit verbringt und sich einig ist, wie die Entwicklung verlaufen soll. Es war immer noch eine größere Hürde für andere.
Kevin

2
Zu beachten ist, dass die Versionskontrolle und das Backup manchmal (wenn auch sehr unterschiedlich) zu einem Designer mit Binärdaten verschmelzen. Sichern kann bereits die Norm sein und daher muss verstanden werden, was er oder sie gewinnt.
Aaron McIver

1
@ Kevin: Was für einen Programmierer einfach, offensichtlich und intuitiv ist, ist für andere Menschen nicht unbedingt etwas Ähnliches, selbst für intelligente und kreative andere Menschen.
David Thornley

1
Verloben Sie sich mit einer Designerin und beauftragen Sie sie privat mit der Versionskontrolle. :)

Antworten:


11

Ich arbeite in einem Team von Entwicklern und Designern und wir alle verwenden die Versionskontrolle. Für die Designer ist es scheiße.

Filesharing / Backup entspricht immer der Versionskontrolle

Wenn du sagst:

Ich lehne es ab, ohne es zu arbeiten, was bedeutet, dass jeder, der an dem Projekt beteiligt ist, es auch benutzen muss. Es ist nur eine gute Übung.

Sie müssen sich der Fallstricke bewusst sein, die bei der Verwendung der Versionskontrolle mit Binärdaten auftreten können:

  • Überschreiben : Wenn zwei Designer an derselben Datei arbeiten, überschreibt der zweite, der festgeschrieben wird, die Änderungen des ersten als die aktuelle Version. Die einzige Möglichkeit, dies zu verhindern, ist das Sperren oder die ständige Kommunikation darüber, wer was mit welcher Datei tut. Beide können den Workflow ihres Teams beeinträchtigen.
  • Zusammenführen : Das werkzeuggestützte Zusammenführen ist in Binärdaten nicht vorhanden. Das manuelle Zusammenführen ist schmerzhaft und führt zu einer großen Anzahl von Fehlern.
  • Aufblähung im Repository: VC-Systeme speichern nur geänderte Zeilen für Textdateien. Dies ist bei Binärdaten nicht möglich, da die gesamte Datei anders aussieht als das VC-System. Dies bedeutet, dass 20 Versionen einer 10-KB-Textdatei möglicherweise nur 20 KB aufnehmen, 20 Versionen einer 1-MB-Datei jedoch wahrscheinlich eher 20 MB. Ein mittelgroßes Designteam kann problemlos viele Revisionen von Dutzenden von Binärdateien generieren. Ihre IT-Abteilung könnte Sie bald für die Speicheranforderungen hassen und möglicherweise sogar für mehr Arbeitsspeicher / CPU auf Ihrem VC-Server.

    Möglicherweise hassen Sie und andere Entwickler auch bald, wie lange das Auschecken oder Aktualisieren dauern kann, es sei denn, Sie haben eine sehr gute Repository-Organisation eingerichtet, um die Binärdateien zu vermeiden.

  • Reduzierter Nutzen : Ihre Designer greifen selten, wenn überhaupt, auf frühere Versionen von Binärdateien zurück, da 1) der Inhalt einer früheren Version nicht einfach überprüft werden kann, 2) die Zusammenführung ohnehin nicht einfach ist und vor allem 3) sie nicht funktionieren So funktioniert das nicht - sie werden verwendet, um alternative Versionen einer Grafik zu erstellen, die möglicherweise in den Produktionsdateien selbst noch nützlich sind.

Für Ihren Code sollten Sie unbedingt VC verwenden, und Sie haben das Recht, dies zu fordern.

Sie müssen jedoch die Annahme überprüfen, dass dies bedeutet, dass jeder Benutzer es auch verwenden muss, und auch, ob es für Designer sogar eine gute Praxis ist (obwohl dies für die Sicherung der Fall ist). Sie sollten die endgültigen Grafikressourcen, die für Ihre Website / Anwendung erforderlich sind, in Ihrer VC speichern. Für Produktionsdateien ist dies jedoch möglicherweise nicht die richtige Lösung.


In Bezug auf das "Repository Bloat": Sie können versuchen, das mit den richtigen Dateiformaten zu umgehen. Dokumentation, die in einem Dokument-Markup-Sprachformat gespeichert ist, und Grafiken, die in einem Grafik-Markup-Sprachformat anstelle der entsprechenden Binärformate gespeichert sind , können sehr hilfreich sein. Die Realisierbarkeit hängt natürlich vom jeweiligen Projekt und der Bereitschaft und Kompetenz der beteiligten Personen ab. ;)
Baelnorn

5
Das Überschreiben geschieht auf VCSs, die nichts wert sind. Was passiert ist, dass Sie zwei Versionen derselben Datei haben. Ja, der HEAD des Repositorys wird zuletzt gespeichert. Die Arbeit des anderen Designers geht jedoch nicht verloren wie auf einer gemeinsam genutzten Festplatte. Ich denke, das ist eine wichtige Unterscheidung.
Berin Loritsch

2
@Berin: Das stimmt, aber einer der Vorteile des modernen VCS ist, dass zwei Personen gleichzeitig an einer Sache arbeiten können und ein Großteil der Abstimmungsarbeit automatisch erfolgt. Bei einer Binärdatei, bei der es keinen sinnvollen Zusammenführungsprozess gibt, ist dies jedoch nicht möglich. Darüber hinaus ist der Leiter des Repository derjenige, den die Leute als "real" betrachten werden.
Jprete

1
Stellen Sie sicher, dass separate Repositorys für sie verwandt werden, da sich der Lebenszyklus für Quellcode und Entwurfsdokumentation unterscheidet. Ich stimme nicht zu, dass Repositories für Designer zum Kotzen sind. Die meiste Zeit wird mit Nachdenken und Modellieren verbracht, ohne viele kleine Änderungen an Dokumenten vorzunehmen. Wir machen es auch zur Regel, das automatische Zusammenführen (für alle in den Repositorys gespeicherten Dateien) zu verbieten und daher die Dateisperrung für Bearbeitungen obligatorisch zu machen. In Kombination mit einer guten Teamkommunikation werden so viele der von Ihnen genannten Nachteile vermieden.
rsp

1
Sie liegen völlig falsch, z. B .: Überschreiben - dies ist kein Problem der Versionskontrolle, im Gegenteil, es hilft Ihnen, es zu erkennen. VC-Systeme speichern nur geänderte Zeilen für Textdateien. - Falsch für Schwachkopf.
Maaartinus

4

Ich lehne es ab, ohne es zu arbeiten, was bedeutet, dass jeder, der an dem Projekt beteiligt ist, es auch benutzen muss. Es ist nur eine gute Übung.

Das ist eine großartige Einstellung, ganz oben mit "Nicht mein Job!" :-)

Der beste Weg, um ein Buy-In zu erhalten, ist die Verwendung von TortoiseGit oder TortoiseSVN, um die Versionskontrolle in den Explorer zu integrieren (vorausgesetzt Windows). Es braucht Zeit, um einen echten Nutzen zu sehen, wenn Sie nicht an das Paradigma der Versionskontrolle gewöhnt sind. Zumindest Tortoise erleichtert die Arbeit mit VCS mit der Maus. Ein einfacher "Rechtsklick -> Einchecken" genügt.

Aus diesem Grund habe ich versucht, eine transparente Versionskontrolle in TortoiseGit für jede Datei zu implementieren, die geschlossen wird. Wenn Sie jemandem eine Verzweigung zum Bearbeiten geben und dann jedes Schreiben / Schließen zu einer Festschreibungsoperation wird, können Sie als Entwickler die Verzweigung irgendwann zusammenführen, ohne sich um die Konsistenz des gesamten Repositorys zu sorgen, und sie können mit der zusammenarbeiten Geschäft zu tun, was sie tun, ohne über die Versionskontrolle zu wissen.

Ich habe das gleiche Problem mit einer großen Anzahl von Audit-Dokumenten, die ich nicht zur Versionskontrolle bringen kann. Wir haben also 50 Versionen desselben Dokuments, die alle auf subtile Weise unterschiedlich sind.


4

Der Weg, dies zu erreichen, besteht darin, ein Build-System (wie Hudson ) einzurichten, das das Versionskontrollsystem verwendet, um die Build-Quellen abzurufen und es zu einer Projektregel zu machen, dass nur Artefakte , die vom Build-System geliefert werden, an das Testteam und gesendet werden eventuell beim Kunden eingesetzt.

Stellen Sie klar, dass alles, was nicht aus dem Build stammt, für den Projektprozess nur den Entwicklern zur Verfügung steht. Solange die Arbeit von jemandem nicht in den Build aufgenommen wird, kann sie genauso gut nicht existieren.


2

Verdeutlichen Sie die Vorteile:

  • Zeigen Sie ihnen, wie sie Zeit sparen können, indem Sie allen die Möglichkeit geben, ihre Arbeit zu teilen und auf einen zentralen Ort zuzugreifen.
  • Zeigen Sie ihnen, wie Designer gleichzeitig an verschiedenen Teilen des Projekts arbeiten und es wieder zusammenführen können.
  • Zeigen Sie ihnen, wie sie ältere Versionen einer Anwendung zum Testen oder zur Fehlerbehebung markieren und erstellen können.
  • Zeigen Sie ihnen, wie sie mit einem Design experimentieren können, und aktualisieren Sie dann das Projekt, ohne die Änderungen beizubehalten, wenn sie dies nicht möchten.
  • Zeigen Sie ihnen, wie sie sehen können, was im Laufe der Zeit passiert ist.

1
-1 Hier ging es darum, Nicht-Programmierer einzubeziehen. Die Liste scheint auf einen Programmierer zugeschnitten zu sein. Wenn du deine Antwort änderst, werde ich auf jeden Fall die Gegenstimme entfernen ...
Aaron McIver

1
Ich denke, Sie haben den Teil "Für Nicht-Programmierer" verpasst. Alle Aufgaben, die Sie erwähnt haben, sind Programmiereraufgaben.
Erik Funkenbusch

Entschuldigung, ich habe gerade die Frage gelesen, nicht den Titel. Ich werde die Antwort bearbeiten.
jzd

1 entfernt ...
Aaron McIver

1

"Nicht mein Job" über die Versionskontrolle ist eine vernünftige Einstellung von einem Nicht-Programmierer.

Erstellen Sie ein Versionskontrollsystem, das so einfach und unsichtbar ist wie Dropbox für die Synchronisierung oder Time Machine für die Sicherung.

Es sollte einfach funktionieren. Kein Checkout, kein Commit. Legen Sie einfach die Dateien in den Projektordner.


1

Ich habe tortoiseHG / mercurial mit der neuen Website-Dame verwendet, dort keine Probleme. Das Auschecken zu vermeiden, macht es sehr einfach und übt den Druck auf die Person aus, die dafür sorgen muss, dass die Dateien synchronisiert werden. Es scheint nicht einmal mehr "etwas zu tun" zu sein, es ist nur "ok, ich werde die Website demo, also muss ich Peter bitten, die Änderungen neu zu synchronisieren." und das ist kein problem.

Ich hatte vorher keine Erfahrung mit Quecksilber, wir verwenden VSS und ich hätte mir das nie für irgendjemanden zur Quellcodeverwaltung gewünscht. Ich habe es einmal versucht und ich würde niemandem die Schuld geben, dass er es nicht benutzen wollte.


0

Ich würde sagen, die Verwendung von Schildkröten-Klonen ist umso einfacher. Oder integrieren Sie die Versionskontrolle in die IDE oder was auch immer.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.