Wie verhindern Teams das Überschreiben von Quelldateien? [geschlossen]


26

Mir ist der Gedanke gekommen, dass, während zum Beispiel die Game-Engine von mehreren Personen gleichzeitig bearbeitet wird, wie das Überschreiben verhindert wird?

Lassen Sie uns sagen Entwickler ein arbeitet an Audio.cppund Entwickler zwei arbeitet auch an Audio.cpp, wie sich dies in der Regel in großen Teams zu bekämpfen Überschreibungs verwaltet? (Mit anderen Worten, um Entwickler 2 daran zu hindern , die Datei zu öffnen, bis Entwickler 1 fertig ist.)


84
Einer der ausgewählten Tags ist bereits die Antwort.
Philipp

18
Tatsächlich sind 3 der 4 Tags eine Antwort, aber eines ist die Antwort.
MSalters

Antworten:


69

Die meisten Softwareentwicklungsteams (nicht nur in der Spieleentwicklung) lösen dieses Problem mit Versionskontrollsoftware . Beispiele sind

Alle diese Tools haben einige Unterschiede, aber der grundlegende Workflow sieht normalerweise so aus: Es gibt ein zentrales Repository für das Projekt mit der vollständigen Codebasis. Wenn ein Entwickler dem Projekt beitreten möchte, führt er einen "Checkout" durch. Die Versionskontrollsoftware kopiert die Codebasis auf ihren lokalen Computer. Die Software merkt sich die aktuelle Version ("Revision") der Codebasis. Wenn ein Entwickler Änderungen vorgenommen hat und diese in das Haupt-Repository übernehmen möchte, führt er ein "Commit" durch. Ihre Änderungen werden in das zentrale Repository hochgeladen und eine neue Revisionsnummer wird erstellt.

Wenn ein anderer Entwickler nun seine Änderungen festschreiben möchte, die einmal ausgecheckte Revision jedoch nicht mehr die neueste ist, werden sie vom Versionskontrollsystem nicht zugelassen. Der Entwickler muss zunächst die in der Zwischenzeit aufgetretenen Revisionen "ziehen". Dadurch wird die lokale Kopie auf die neueste Version im zentralen Repository aktualisiert. Bei Konflikten (Änderungen, die zwischenzeitlich an einer Datei vorgenommen wurden) werden Sie möglicherweise von der Software aufgefordert, den Konflikt zu lösen, indem Sie die in Konflikt stehenden Dateien manuell bearbeiten ("Zusammenführen"), falls dies nicht automatisch möglich ist. Danach können sie ihre Änderungen als neue Revision übernehmen.


18
Beachten Sie, dass Git und Mercurial verteilt sind Versionskontrollsysteme sind, die ein wenig anders funktionieren: Sie erfordern kein einziges zentrales Repository, ermöglichen es jedoch theoretisch jedem Entwickler, Aktualisierungen direkt von anderen abzurufen. In der Praxis ist es natürlich immer noch üblich, dass ein Repository (häufig auf einem öffentlichen Host wie GitHub) als "offiziell" deklariert und mehr oder weniger wie das zentrale Repository in einem nicht verteilten Versionskontrollsystem verwendet wird.
Ilmari Karonen

18
Diese Antwort impliziert auch, dass das Zusammenführen immer manuell erfolgt. Meistens kann die Versionskontrollsoftware jedoch Unterschiede automatisch zusammenführen und erfordert nur manuelle Arbeit für wirklich heikle Änderungen.
jhocking

Bitte vermeiden Sie längere Diskussionen in Kommentaren. Dies ist kein Diskussionsforum. Verwenden Sie den Spieleentwicklungs-Chat, wenn Sie dies möchten. Ich habe einige tangentiale Kommentarthreads aufgeräumt.
Josh

Idealerweise ist jedes Teammitglied fast ausschließlich für bestimmte Module verantwortlich, und nur in seltenen Fällen ändert mehr als eine Person dieselbe Quelldatei innerhalb kurzer Zeit, da durch diesen Workflow die Notwendigkeit minimiert wird, widersprüchliche Änderungen zusammenzuführen. Das ist aber nicht immer der Fall.
Nicolas Miari

13

Entwickler verwenden nicht dieselbe Datei.

Jeder Entwickler hat seine eigene Version der Datei und verwendet eine spezielle Software, um seine Arbeit zu verwalten. Wenn beide Änderungen daran vornehmen, stößt derjenige, der versucht, die vom anderen Entwickler vorgenommenen Änderungen zu überschreiben, auf einen Konflikt, der gelöst werden muss. Andernfalls beschwert sich die Software, über die ich gesprochen habe. Mit anderen Worten, der Entwickler, der den Konflikt verursacht, muss seine Arbeit mit der Arbeit des anderen Entwicklers kombinieren, und erst dann kann die Datei "gespeichert" werden.

Dies ist eine einfache Erklärung für einen Teil des ansonsten nicht so einfachen Konzepts der Versionskontrolle .


6
Außerdem machen sie dieses neuartige Ding namens Kommunizieren und Software wird nicht in einem luftleeren Raum geschrieben. Wenn sie den Konflikt nicht verstehen, sprechen sie mit der anderen Person oder koordinieren ihn vorher.
Brian

9

Zusätzlich zu den Punkten, die in den anderen Antworten zur Versionskontrolle und zur Behandlung von Konflikten mit Zusammenführungen angesprochen wurden, gibt es mindestens zwei weitere Möglichkeiten, mit denen Teammitglieder vermeiden können, dass die Arbeit des anderen überschrieben wird:

  • Einige Versionskontrollsysteme (zB SVN) erlauben das Sperren von Dateien. Dies bedeutet, dass ein Teammitglied für einige Zeit das ausschließliche Eigentum an einer Datei übernehmen kann, wodurch andere Teammitglieder daran gehindert werden, widersprüchliche Änderungen (oder überhaupt Änderungen) vorzunehmen, bis die Datei anschließend entsperrt wird.

    Dies wird jedoch im Allgemeinen selten verwendet, da es eine Reihe von Problemen verursachen kann. Dies kann die Produktivität verringern (indem eingeschränkt wird, wer zu einem bestimmten Zeitpunkt an Dateien arbeiten kann) und Probleme verursachen, wenn jemand vergisst, eine Datei zu entsperren. Zumindest für SVN (bei anderen VCSs bin ich mir nicht sicher) verhindert das Sperren einer Datei nicht, dass andere Personen Änderungen an ihrer Arbeitskopie vornehmen, sondern dass sie ihre Änderungen übernehmen. Dies kann für Entwickler zu unnötiger Anstrengung führen Ändert die Datei nur, um festzustellen, dass sie ihre Änderungen nicht übernehmen können, da sie gesperrt sind.

  • Teams können versuchen, den Entwicklern Aufgaben so zuzuweisen, dass zu einem bestimmten Zeitpunkt nicht mehr als eine Person an einer bestimmten Datei arbeitet. Beispielsweise können Entwickler jeweils für einen bestimmten Teil des Projekts verantwortlich sein (z. B. 3D-Rendering, Netzwerk, Audio usw.). Wenn die Codebasis gut modularisiert ist, muss der dem Netzwerkcode zugewiesene Entwickler die Dateien kaum berühren Umgang mit Audio.

    Natürlich wird es immer einige Überlappungen geben, die auf andere Weise verwaltet werden müssen.


2
Auf der positiven Seite ist das Sperren die einzige Möglichkeit, eine .JPEG-Datei oder eine andere Nicht-Nur-Text-Datei zu bearbeiten. Dies ist keine theoretische Einschränkung, es ist nur so, dass die Zusammenführungswerkzeuge normalerweise nicht funktionieren.
MSalters

2
@MSalters Es ist nicht so, dass die Werkzeuge scheiße sind, sondern nur, dass die meisten Zusammenführungswerkzeuge für Text und nicht für Binärdaten erstellt wurden. Und wie würden Sie einen Konflikt lösen, wenn zwei Änderungen das gleiche Pixel in einer Datei ändern würden? Oder noch schlimmer: Wie würden Sie die durch die JPEG-Komprimierung verursachten Änderungen berücksichtigen? Es ist ein sehr komplexes Problem, für das es möglicherweise nicht einmal eine gute Lösung gibt. Der Grund dafür, dass die meisten Merge-Tools dies nicht unterstützen, liegt darin, dass dies sehr selten erforderlich und die Funktionalität schwierig zu implementieren ist.
Maurycy

3
@ MaurycyZarzycki: Das Ändern desselben Buchstabens ähnelt dem Ändern desselben Pixels: Dies erfordert eine manuelle Auflösung. .JPEG war wahrscheinlich ein schlechtes Beispiel, da Künstler nicht an verlustbehafteten Formaten arbeiten. Das Zusammenführungsproblem besteht jedoch auch bei .PNG. Zumindest würden Sie gerne wissen, ob Merge-Tools XML zusammenführen können, ohne es zu beschädigen.
MSalters

@MSalters Klar, da kann ich noch viel mehr zustimmen.
Maurycy

1
@xorsyst: Probieren Sie es so aus: Checken Sie von SVN an zwei Orten aus. Sperren Sie dann eine Datei von Speicherort 1. Speicherort 2 weiß erst, dass sie gesperrt ist, wenn sie festgeschrieben oder aktualisiert wurde.
Zan Lynx,
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.