Was ist ein Versionskontrollsystem. Eine gemeinsame Funktion aller Revisionskontrollsysteme ist die Funktion, die es uns ermöglicht, frühere Änderungen rückgängig zu machen. TortoiseSVN-Funktionen. Shell-Integration

Bei jeder Operation, die ich gemessen habe, schneidet Mercurial besser ab als Subversion. Die Geschwindigkeit ist 2-6 mal schneller, wenn es darum geht lokal Subversion 1.4.3-Repositorys (die meisten schnelle Methode betreten). In einem realistischeren Anwendungsfall, einem Online-Repository, ist Subversion in einer viel schlechteren Position. Da Subversion-Befehle mit dem Server kommunizieren müssen und es Subversion an nützlichen Replikationsfunktionen, Serverleistung und Durchsatz Netzwerke werden selbst bei kleinen Projekten zu Engpässen.

Darüber hinaus benötigt Subversion zusätzlichen Speicherplatz, um Netzwerkanfragen zu vermeiden, wenn einige Operationen ausgeführt werden: das Auffinden von geänderten Dateien (Status) und das Anzeigen von Änderungen (Diff). Das Ergebnis ist eine Subversion-Arbeitskopie, die dieselbe Größe (wenn nicht sogar größer) hat wie das Mercurial-Repository und das Arbeitsverzeichnis zusammen, obwohl das Mercurial-Repository die vollständige Historie des Projekts enthält.

Subversion bietet umfassende Unterstützung für Toolkits von Drittanbietern. Hier hinkt Mercurial derzeit hinterher. Obwohl sich die Lücke schließt, übertreffen einige der GUI-Dienstprogramme für Mercurial ihre Subversion-Pendants. Wie Mercurial hat Subversion ein ausgezeichnetes Benutzerhandbuch.

Da Subversion keine Änderungshistorie auf dem Client speichert, ist es gut geeignet, um Projekte zu verwalten, die eine große Anzahl von Binärdateien enthalten. Wenn Sie 50 Änderungen an einer inkompressiblen 10-Megabyte-Datei vornehmen, bleibt der von Subversion belegte Speicherplatz unverändert. Der von jedem der verteilten Revisionskontrollsysteme belegte Speicherplatz wird proportional zur Anzahl der Änderungen schnell anwachsen, da die Unterschiede zwischen den Revisionen groß sind.

Außerdem ist es normalerweise schwierig, wenn nicht unmöglich, verschiedene Versionen einer Binärdatei zusammenzuführen. Subversion erlaubt einem Benutzer, eine Datei zu sperren, was dem Benutzer exklusive Rechte gibt, sie vorübergehend zu ändern. Dies kann ein erheblicher Vorteil für ein Projekt sein, das häufig Binärdateien verwendet.

Mercurial kann den Änderungsverlauf aus einem Subversion-Repository importieren. Auch der umgekehrte Vorgang ist möglich. Dies ermöglicht es, die Gewässer zu testen und sowohl Mercurial als auch Subversion gleichzeitig zu verwenden, bevor Sie sich entscheiden, ob Sie migrieren oder nicht. Das Konvertieren einer Story ist ein schrittweiser Prozess, sodass Sie die anfängliche Konvertierung durchführen und dann neue Änderungen vornehmen können.

1.6.2. Git

Git ist ein verteiltes Versionskontrollsystem, das entwickelt wurde, um den Quellcode des Linux-Kernels zu verwalten. Wie bei Mercurial wurde das ursprüngliche Design des Systems von Monotone beeinflusst.

Git bietet eine große Liste von Befehlen mit 139 einzigartigen Befehlen in Version 1.5.0. Es hat den Ruf, schwer zu erlernen. Im Vergleich zu Git legt Mercurial Wert auf Einfachheit.

Wenn es um Leistung geht, ist Git sehr schnell. In einigen Fällen ist es schneller als Mercurial (zumindest unter Linux), in anderen ist es schneller als Mercurial. Unter Windows sind jedoch sowohl die Leistung als auch der allgemeine Support zum Zeitpunkt dieses Schreibens für Git viel schlechter als für Mercurial.

Während das Mercurial-Repository keine Operationen auf Wartung, ein Git-Repository erfordert häufige manuelle "Umpacken" eigene Metadaten. Wenn dies nicht geschieht, beginnt die Leistung zu sinken, zusammen mit einer Zunahme des verwendeten Speicherplatzes. Ein Disk-Array eines Servers, das mehrere Git-Repositorys enthält, gegen die die strenge Regel der häufigen "Umpacken", früher oder später überlastet, wodurch der Prozess der täglichen Exemplar reservieren kann leicht über 24 Stunden dauern. Gerade "Verpackt" Das Git-Repository nimmt etwas weniger Platz ein als das Mercurial-Repository, aber das ungepackte Repository wird um mehrere Größenordnungen größer sein.

Der Kern von Git ist in C geschrieben. Viele der Git-Befehle sind als Shell-Skripte oder Skripte in der Sprache Perl und die Qualität dieser Skripte variiert stark. Ich habe mehrere Installationen gesehen, bei denen die Ausführung von Skripten trotz schwerwiegender Fehler dummerweise fortgesetzt wurde.

Mercurial bietet die Möglichkeit, den Versionsverlauf aus einem Git-Repository zu importieren.

1.6.3. CVS

CVS ist wahrscheinlich das am weitesten verbreitete Versionskontrollsystem der Welt. Dank seines ehrwürdigen Alters und des Chaos, das im Inneren herrscht, wurde es seit vielen Jahren sehr schlecht gepflegt.

CVS basiert auf einer zentralisierten Client-Server-Architektur. Es gruppiert Dateiänderungen nicht in atomare Commits, so dass die Benutzer leicht "Break den Build": Eine Person kann einige der Änderungen erfolgreich in das Repository übertragen und dann aufgrund der Notwendigkeit einer Zusammenführung blockiert werden. Dies führt zu einer Situation, in der der Rest der Teilnehmer nur einen Teil der Änderungen sieht, die sie hätten sehen sollen. Diese Funktion wirkt sich auch darauf aus, wie Sie mit dem Änderungsverlauf arbeiten. Wenn Sie alle Änderungen abrufen möchten, die ein Teammitglied zur Lösung eines bestimmten Problems vorgenommen hat, müssen Sie die Beschreibungen und das Datum der vorgenommenen Änderungen für jede betroffene Datei manuell recherchieren (wenn Sie wissen, welche Dateien überhaupt betroffen waren).

CVS arbeitet mit einem ziemlich verworrenen Konzept von Branches und Tags, das ich in diesem Buch nicht einmal versuchen werde zu beschreiben. Es unterstützt nicht das Umbenennen von Dateien und Ordnern, so dass das Repository ziemlich leicht beschädigt werden kann. Da es praktisch keine internen Mechanismen zur Integritätskontrolle gibt, lässt sich oft nicht einmal mit Sicherheit sagen, ob ein Repository beschädigt wurde und wenn ja, wie. Daher würde ich CVS für kein bestehendes oder neues Projekt empfehlen.

Mercurial bietet die Möglichkeit, den CVS-Versionsverlauf zu importieren. Hier gibt es jedoch einige Fallstricke, auf die auch jedes andere CVS-Importtool stoßen wird. Fehlen atomarer Änderungen und Versionierung hierarchischer Daten Dateisystem macht es unmöglich, den Verlauf von CVS-Änderungen vollständig zu rekonstruieren, so dass in einigen Fällen Annahmen verwendet werden und Umbenennungen normalerweise nicht angezeigt werden. Da viele CVS-Verwaltungsaufgaben manuell durchgeführt werden müssen, was das Fehlerrisiko erhöht, gibt der CVS-Importer häufig viele Repository-Integritätsfehler zurück (völlig unrealistische Revisionsdaten und Dateien, die in den letzten zehn Jahren gesperrt geblieben sind, sind nur ein paar der am wenigsten interessanten Probleme, an die ich mich aus eigener Erfahrung erinnern kann).

«

1.8. Eine kurze Geschichte der Versionskontrolle

Das bekannteste der älteren Versionskontrollprogramme ist SCCS (Source Code Control System), das Anfang der 70er Jahre von Marc Rochkind von Bell Labs geschrieben wurde. SCCS betrieben separate Dateien und erforderte, dass jeder, der an einem Projekt arbeitet, Zugriff auf einen einzigen freigegebenen Arbeitsbereich hat. Es kann immer nur eine Person eine Datei gleichzeitig bearbeiten; Dateizugriffskonflikte wurden durch Sperren gelöst. Eine häufige Situation bestand darin, dass vergessen wurde, die Sperre nach der Bearbeitung aufzuheben, was verhinderte, dass andere Personen ohne die Hilfe eines Administrators auf die Datei zugreifen konnten.

Walter Tichy entwickelte Anfang der 1980er Jahre eine kostenlose Alternative zu SCCS; er nannte sein Programm RCS (Revision Control System). Wie SCCS verlangte RCS von Entwicklern, dass sie sowohl in einem einzigen gemeinsamen Arbeitsbereich arbeiten als auch Dateien sperren, um zu verhindern, dass verschiedene Personen Dateien gleichzeitig ändern.

Später, in den 1980er Jahren, verwendete Dick Grune RCS als Grundlage für eine Reihe von Shell-Skripten, die ursprünglich cmt hießen und später in CVS (Concurrent Versions System) umbenannt wurden. Eine wichtige Neuerung in CVS war, dass Entwickler gleichzeitig und teilweise unabhängig in ihren persönlichen Arbeitsbereichen arbeiten konnten. Es waren diese Räume, die verhinderten, dass sich Entwickler ständig auf die Fersen traten, was in SCCS und RCS üblich war. Jeder Entwickler hatte eine Kopie jeder Projektdatei, Entwickler konnten ihre Kopien unabhängig ändern. Sie mussten nur ihre eigenen Änderungen zusammenführen, bevor sie die Änderungen an das zentrale Repository übermittelten.

Brian Berliner nahm Grüns ursprüngliche Skripte und schrieb sie in C um, wobei er 1989 Code veröffentlichte, der später in die moderne Version von CVS mündete. CVS erwarb später die Fähigkeit, über das Netzwerk zu arbeiten, und erhielt eine Client-Server-Architektur. Die CVS-Architektur ist zentralisiert: Nur der Server hat eine Kopie der Projekthistorie. Client-Arbeitskopien enthielten nur die neuesten Dateiinstanzen und kleine Metadaten, um den Server zu lokalisieren. CVS hat einen beispiellosen Erfolg erzielt: Es ist das wahrscheinlich am weitesten verbreitete Versionskontrollsystem der Welt.

In den frühen 1990er Jahren entwickelte Sun Microsystems ein frühes verteiltes Revisionskontrollsystem namens TeamWare. Jede TeamWare-Arbeitskopie enthielt eine vollständige Kopie des Projektrevisionsverlaufs. Das Konzept eines zentralen Repositorys in TeamWare fehlte als solches. (Ähnlich wie bei CVS, das RCS zum Speichern des Verlaufs verwendet, verwendet TeamWare SCCS.)

Im Verlauf der 1990er Jahre wuchs das Bewusstsein für mehrere CVS-Themen. Das System zeichnet gleichzeitige Änderungen an mehreren Dateien separat auf, anstatt sie in einer logisch atomaren Operation zu gruppieren. Die Art und Weise, wie Sie Ihre Dateihierarchie verwalten, ist nicht sehr gut; Sie können Ihr Repository leicht durcheinander bringen, indem Sie Dateien und Verzeichnisse umbenennen. Außerdem ist der CVS-Quellcode nicht leicht zu verstehen und zu warten, was ihn fast unwiderstehlich macht. "Schmerzgrenze" Fixes für diese Architekturprobleme.

2001 begannen Jim Blandy und Karl Fogel – zwei Entwickler, die zuvor an CVS gearbeitet hatten – ein Projekt, um es durch ein Tool mit besserer Architektur und saubererem Code zu ersetzen. Das Ergebnis – Subversion – entfernte sich nicht vom zentralisierten Client/Server-Modell von CVS, sondern fügte atomare Commits für mehrere Dateien, eine bessere Namespace-Verwaltung und andere Funktionen hinzu, die Subversion zu einem besseren Werkzeug als CVS machten. Seit der Veröffentlichung der ersten Version hat Subversion schnell an Popularität gewonnen.

Mehr oder weniger gleichzeitig begann Graydon Hoare mit der Arbeit an einem ehrgeizigen Versionskontrollsystem namens Monotone. Dieses System beseitigt nicht nur viele Probleme internes Gerät CVS hat eine verteilte Architektur, geht aber in einigen Neuerungen über mehrere frühere (und spätere) Versionskontrollsysteme hinaus. Monotone verwendet kryptografische Hashes als Identifikatoren und hat ein inhärentes Verständnis von „ Vertrauen " Code aus verschiedenen Quellen.

Das Leben von Mercurial begann 2005. Während einige Aspekte seiner Architektur von Monotone beeinflusst wurden, konzentriert sich Mercurial auf Benutzerfreundlichkeit, hohe Leistung und Skalierbarkeit für sehr große Projekte.

Sie haben eine großartige Geschäftsidee für die Softwareentwicklung?Sie müssen sich technologisch entwickeln schwierige Entscheidung? Oder haben Sie ein großes Team von Programmierern, die an derselben Aufgabe arbeiten? Dann merken Sie sich diese drei Wörter:Versionskontrollsystem .

Versionskontrollsystem (cvs), 2017 - Vergleich: Git, SVN, Mercurial

, oder vcs- Das verhindert, dass das Projekt auseinanderfällt, wenn viele Leute daran arbeiten. Programmierer, Manager, Texter können an ihrem eigenen Stück arbeiten, ohne sich gegenseitig zu stören und ohne Schäden zu verursachen, die nicht behoben werden könnten.

Wenn Sie mit dem Konzept noch nicht vertraut sindVersionskontrollsysteme dann hier alles wird sehr deutlich gezeigt.

Oder sehen Sie sich das Video von GitHub an.

Welches Versionsverwaltungssystem ist also das richtige für Ihr Projekt?

Wir haben verschiedene gängige Lösungen verglichen, um Ihnen die Auswahl zu erleichtern.

Dies ist ein hochspezialisiertes technisches Thema. Wir haben versucht, unsere Bewertung für alle verständlich zu machen. Wenn Sie jedoch keine Programmiererfahrung haben, wenden Sie sich an Ihre Entwicklungsabteilung, bevor Sie Entscheidungen treffen.

Versionskontrollsysteme, einschließlich des bekannten SVN (Subversion) und Git, wurden ursprünglich geschaffen, damit Entwicklungsteams an gemeinsamen Projekten arbeiten können, ohne Verwirrung zu stiften. In einem Kontrollsystem müssen Sie Codeverzweigungen nicht unabhängig verfolgen und Notizen dazu studieren. Stattdessen wird ein zentrales Repository verwendet, in dem alles geordnet und strukturiert ist. Es ist bequem, hier Dateien zu aktualisieren, Kommentare hinzuzufügen und sogar Projektzweige zusammenzuführen.

Meinungen, welcheVersionskontrollsystemdie besten, sie variieren stark, was zu hitzigen Debatten unter Programmierern führt. Abholen und studierenVersionskontrollsystemeDenken Sie bei Ihrem Projekt daran, dass der Nutzen einer Lösung oft subjektiv ist. Zum Beispiel die persönlichen Vorlieben des Programmierers oder beispielsweise Indikatoren wie Leistung, IDE-Plugin-Fähigkeiten usw.

Der Hauptunterschied zwischen Versionskontrollsystemen besteht darin, ob sie Client-Server oder dezentral (p2p) sind. Haben sie ein zentrales Repository (Server), woher der Code kommt und wo er mit den vorgenommenen Änderungen zurückgegeben wird. Oder ist es eine Kopie in lokaler Speicher Peer-aktualisierbar: ein stärker dezentralisiertes Netzwerk, das zur Synchronisation, zum Austausch von Patches (Changesets) und zur Pflege des aktuellen Codes verwendet wird.

Es lohnt sich auch, die Leistung, Funktionalität und die Schwelle zum Eingeben / Beherrschen eines bestimmten zu berücksichtigenKontroll systeme... Betrachten wir die häufigstenVersionskontrollsystemeund die Gründe, warum Programmierer bestimmte Lösungen bevorzugen.

Das System der gleichzeitigen Versionen (CVS)

CVS erschien in den 1980er Jahren und ist sowohl bei kommerziellen Produktentwicklern als auch bei Open-Source-Entwicklern immer noch beliebt.

CVS gilt zu Bedingungendes GNU Open License Agreement und ermöglicht es Ihnen, die erforderliche Version des Projekts vom Server zu erhalten - “Auschecken " und dann zurück an den Server weiterleiten",Einchecken "(Rückkehr),wie geändert.

Ursprünglich CVS wurde erstellt, um Versionskonflikte zu vermeiden. Alle Teilnehmer erhielten nur das Beste letzte Version Code. Dies war das erste Versionskontrollsystem. Der Benutzer musste Änderungen schnell in das Repository übernehmen, bevor andere ihm voraus waren.

Jetzt CVS hat Unterstützung für die Arbeit an Projekten mit Code-Branches. Es stellt sich heraus, dass mehrere Produktoptionen mit verschiedene Eigenschaften die später zusammengeführt werden können.

CVS-Server läuft normalerweise unter Unix, aber CVS -Clients sind auch in anderen beliebten Betriebssysteme Oh. CVS - "reif", bewährtVersionskontrollsystem... Es ist immer noch ein Open-Source-System, aber heute werden nur noch selten neue Funktionen hinzugefügt.

Gleichzeitig ist CVSNT eine Version, die in einem separaten Projekt veröffentlicht wurde. CVS zum Windows-Server, - erweitert nun aktiv seine Funktionalität.

Vorteile:

• Bewährte Technologie, die seit Jahrzehnten auf dem Markt ist.

Nachteile:

• Das Umbenennen oder Verschieben von Dateien wird nicht im Verlauf widergespiegelt
• Sicherheitsrisiken im Zusammenhang mit symbolischen Links zu Dateien
• Keine Unterstützung für atomare Operationen, die zu Codekorruption führen können
• Filialbetrieb Programmcode teuer seit demKontrollsystemnicht für langfristige Projekte mit Code-Branches gedacht

Apache-Subversion (SVN)

SVN wurde als Alternative erstellt CVS um Mängel zu beheben CVS und sorgen gleichzeitig für eine hohe Kompatibilität damit.

Wie CVS SVN ist ein kostenloses System. Versionskontrolle Open Source. Der einzige Unterschied besteht darin, dass es unter der Apache-Lizenz vertrieben wird und nicht unterDie GNU Open-Lizenzvereinbarung.

Um die Integrität der Datenbank zu wahren, verwendet SVN sogenannte atomare Operationen. Wenn eine neue Version veröffentlicht wird, werden entweder alle oder keine der Fixes auf das Endprodukt angewendet. Somit ist der Code vor chaotischen Teilbearbeitungen geschützt, die nicht miteinander übereinstimmen und Fehler verursachen.

Viele Entwickler sind umgestiegenSVN seit neue Technologie die besten Funktionen geerbt CVS und gleichzeitig erweitert.

Im CVS Operationen mit Code-Verzweigungen sind teuer und von der Systemarchitektur nicht vorgesehen, dafür wurde SVN entwickelt. Das heißt, für größere Projekte mit Code-Verzweigung und vielen Entwicklungsbereichen.

Die Nachteile von SVN werden vergleichend genannt langsame Geschwindigkeit und das Fehlen einer verteilten Versionskontrolle. Verteilt Versionskontrolle verwendet ein Peer-to-Peer-Modell anstelle eines zentralisierten Servers, um Codeaktualisierungen zu speichern. Während das Peer-to-Peer-Modell in Open-Source-Projekten besser funktioniert, ist es in anderen Fällen nicht ideal. Der Nachteil des serverseitigen Ansatzes besteht darin, dass die Clients bei einem Serverabsturz keinen Zugriff auf den Code haben.

Vorteile:

• Systembasiert CVS
• Ermöglicht atomare Operationen
• Zweigniederlassungen sind kostengünstiger
• Große Auswahl an IDE-Plugins
• Verwendet kein Peer-to-Peer-Modell

Nachteile:

• Fehler bleiben bestehen im Zusammenhang mit dem Umbenennen von Dateien und Verzeichnissen
• Unbefriedigender Befehlssatz für die Arbeit mit dem Repository
• Relativ niedrige Geschwindigkeit

Git

Dieses System wurde geschaffen, um die Entwicklung des Linux-Kernels zu verwalten und verfolgt einen Ansatz, der sich grundlegend von CVS und SVN unterscheidet.

Die Basis Git Konzepte wurden gelegt, um eine schnellere verteilteVersionskontrollsystem, im Gegensatz zu den Regeln und Entscheidungen, die in CVS ... Da Git hauptsächlich für Linux entwickelt wurde, läuft es auf diesem Betriebssystem am schnellsten.

Git läuft auch auf Unix-ähnlichen Systemen (wie MacOS), und das mSysGit-Paket wird verwendet, um auf der Windows-Plattform zu laufen.

Code ist möglicherweise nicht verfügbar, wenn Sie einen Computer ohne Repository verwenden. Es gibt Workarounds, um dieses Problem zu lösen, und einige Entwickler glauben, dass die Leistung von Git ein fairer Preis für die Unannehmlichkeiten ist.

Darüber hinaus verfügt Git über viele Tools zum Navigieren des Änderungsverlaufs. Jede Arbeitskopie des Quellcodes enthält die gesamte Entwicklungsgeschichte, was beim Programmieren ohne Internetverbindung äußerst nützlich ist.

Vorteile:

• Perfekt für alle die hassen CVS / SVN
• Deutliche Leistungssteigerung
• Günstiger Filialbetrieb
• Vollständiger Entwicklungsverlauf offline verfügbar
• Verteiltes Peer-to-Peer-Modell

Nachteile:

• Hohe Eintrittsschwelle (Lernen) für diejenigen, die zuvor SVN genutzt haben
• Begrenzt Windows-Unterstützung(im Vergleich zu Linux)

Mercurial

Mercurial wurde gleichzeitig mit Git veröffentlicht. es ist das gleiche verteilt Versionskontrollsystem.

Mercurial wurde als Alternative zu Git für die Entwicklung von Linux-Kernel-Modulen entwickelt. Aber seit sie sich für Git entschieden haben, wird Mercurial weniger verwendet. Trotzdem arbeiten zum Beispiel viele führende Entwickler mit diesem speziellen SystemOpenOffice.org .

Das Versionskontrollsystem von Mercurial ist andersVersionskontrollsysteme, dass es hauptsächlich in Python (nicht C) geschrieben ist. Einige Teile sind jedoch als Erweiterungsmodule in C implementiert.

Da das System dezentralisiert und in Python geschrieben ist, neigen viele Python-Programmierer zu Mercurial.

Benutzer bemerken, dass Mercurial einige der Eigenschaften von SVN beibehält, obwohl es ein verteiltes System ist, und aufgrund dieser Ähnlichkeit eine niedrigere Eintrittsschwelle für diejenigen hat, die bereits mit SVN vertraut sind. Außerdem ist die Dokumentation für Mercurial vollständiger, was Ihnen hilft, sich schnell mit den Unterschieden vertraut zu machen.

Einer der größten Nachteile von Mercurial besteht darin, dass es im Gegensatz zu Git keine zwei übergeordneten Zweige zusammenführen kann, da Mercurial ein Plugin-System verwendet und keine Skriptunterstützung. Das ist für einige Programmierer großartig, aber viele wollen die Fähigkeiten von Git nicht aufgeben.

Vorteile:

• Leichter zu erlernen im Vergleich zu Git
• Ausführliche Dokumentation
• Verteiltes ModellVersionskontrollsysteme

Nachteile:

• Es gibt keine Möglichkeit, zwei übergeordnete Zweige zusammenzuführen
• Plugins verwenden, keine Skripte
• Weniger Raum für individuelle Lösungen

WelcherVersionskontrollsystem passt zu mir?

Die meiste Zeit verwenden Entwickler CVS weil es ihnen vertrauter ist. Wenn das Team bereits an einem Projekt arbeitet, dann die Aussicht, alle Entwicklungen auf ein anderes zu übertragenKontrollsystemirgendwie nicht inspirierend. Wenn sie das System ändern müssten, würden sie höchstwahrscheinlich zu SVN wechseln.

CVS hat bereits den Status einer „ausgereiften Technologie“ erreicht, d. h. es wird keine radikal neuen Features und Lösungen mehr geben. Die Trägheit der Gewohnheit geht verloren, wenn die Leute zu SVN wechseln. Damit gehört CVS nach und nach der Vergangenheit an.

Heute hält SVN die Palme unter den ServernVersionskontrollsysteme... Es beinhaltet die Vorteile CVS und übertrifft sie. Wenn wir über Prävalenz sprechen, ist die Wahrscheinlichkeit höher, dass Sie auf CVS oder SVN als bei Git oder Mercurial. Daher wird Ihnen der Umstieg erleichtert, wenn Sie über eine Servertechnologie verfügen, die zwar nicht unbedingt erforderlich ist.

Aufgrund der weit verbreiteten Nutzung und Reife der Technologie verfügt SVN über eine große Wissensdatenbank, die es Benutzern leicht macht, Hilfe zu erhalten.

Git ist eindeutig schneller als die Konkurrenz. Für Projekte, die für verteilte . erstellt wurdenVersionskontrollsysteme, dies ist eine offensichtliche Verbesserung.

Ein wesentlicher Nachteil von Git ist, dass es manchmal schwierig ist, die Nuancen der Arbeit von diesem zu erklärenKontroll systemeund es verlangsamt den Workflow, während sich die Programmierer daran gewöhnen. Sobald jedoch die „Einstiegsschwelle“ überwunden ist, zahlen sich Produktivitätssteigerungen und die komfortable Verwaltung von Code-Zweigen voll aus.

Für diejenigen, die Git hassen (und das System hat seine Gegner in der Entwickler-Community), ist Mercurial ein Kompromiss zwischen SVN und Git. Dieses System wird in vielen bekannten Projekten eingesetzt und verfügt auch über eine gute Dokumentation.

Kompatibel mit Windows-Version Git macht auch Fortschritte und nähert sich der Linux-Version in Bezug auf die Leistung, sodass dieses System für Sie relevant sein kann, auch wenn Sie nicht unter Linux entwickeln.

Berücksichtigen Sie die Besonderheiten des Projekts und Ihres Teams, um zu verstehen, welches für Sie am besten geeignet ist. Sprechen Sie mit den Entwicklern!

Wenn Ihr Projekt erfordert, dass ein einzelner Quellbaum von einer kleinen Gruppe von Programmierern bearbeitet wird, dann ist SVN Ihre Option. Es ist zuverlässig und genau für solche Fälle konzipiert.

Wenn Sie ein Open-Source-Projekt betreiben, an dem mehrere Programmierer zu unterschiedlichen Zeiten arbeiten, oder wenn es so sein soll ständige Erneuerung code, und wählen Sie dann Git. Die Geschwindigkeit und Verwaltung des Quellbaums ist hier viel besser als in SVN.

Wenn Sie an einem Scheideweg stehen oder die Funktionsweise von SVN oder Git einfach nicht mögen, dann ist Mercurial für Sie da.

Alle diese Systeme sind voll funktionsfähig. Und auch kostenlos. Sie werden verwendet, um Software, Websites und sogar Betriebssysteme zu erstellen, die Sie verwenden und mit denen Sie vertraut sind.

Entscheiden Sie zunächst, ob das eine oder andere geeignet istKontrollsystemVersionen für Ihr Unternehmen und stellen Sie dann - ebenso wichtig - sicher, dass die Wahl Programmierer nicht verärgert.

Erste Schritte mit SVN

Wenn Sie noch nie mit SVN oder Git gearbeitet haben und keine Ahnung haben, wie Sie anfangen sollen, dannHosting-Lösung kombiniert mit grafische Oberfläche helfen Ihnen, schnell auf den neuesten Stand zu kommen.

Wie in den meisten Fällen ist es das Wichtigste, anzufangen, und dann kommt das Verständnis. Der Betrieb eines Versionskontrollsystems ist dem Arbeiten mit Dateien auf einem Server mit einem FTP-Client sehr ähnlich.

HINWEIS:Es gibt viele Hosting-Lösungen fürVersionskontrollsysteme, einschließlich derjenigen mit einer kostenlosen Testphase. Sie können Ihr erstes Repository (ein Ort zum Arbeiten mit Codedateien) auf deren Basis kostenlos erstellen. Einige dieser Dienste sind:

Hosten von SVN & GIT

Erstellen des ersten Repositorys

Nachdem Sie ein Konto erstellt haben, müssen Sie ein Repository erstellen - für jede Plattform separat. Normalerweise sieht es so aus:

• Melden Sie sich bei Ihrem Konto an, klicken Sie auf Ihre Projekte.
• Projekterstellung:

• Geben Sie in der Zeile "Neues Projekt erstellen" den Namen Ihres Projekts ein
• Klicken Sie auf die Schaltfläche "Projekt erstellen"

• SVN-Verbindung:

• Wählen Sie nach dem Anlegen des Projekts den Reiter "Quellcodeverwaltung" (Quellcode-Versionen)
• Klicken Sie auf den Link "Quellcodeverwaltung aktivieren"
• Geben Sie dem Repository einen Namen
• Klicken Sie auf "Speichern"

Grafische SVN- und GIT-Clients

Das Repository wird also erstellt. Jetzt müssen Sie alles darin einfach und übersichtlich darstellen. Dazu benötigen Sie eine grafische Oberfläche.

— komfortables Programm arbeiten mitVersionskontrollsystemev Microsoft Windows und möglicherweise der beste Apache Subversion-Client auf dem Markt. TortoiseSVN ist als Windows-Shell-Erweiterung implementiert, was die Integration in Browser. Darüber hinaus handelt es sich um ein Open-Source-Programm, für das 34 Sprachpakete verfügbar sind.

SmartGit

- grafischer Git-Client (Open Source verteiltVersionskontrollsystem). Funktioniert unter Windows, Mac OS X und Linux.Lizenzkosten - $ 39

"Auschecken" des Repositorys ("Auschecken")

Der Kunde ist also ausgewählt. Nun müssen Sie ein Repository für das Steuerungssystem erstellen. Sie müssen eintretenIhre Repository-URL, Ihr Benutzername und Ihr Passwort.

Die URL sieht normalerweise so aus:https: // svn .hostname.com / svn / > (Sie können https:// (SSL) verwenden, wenn Sie ein kostenpflichtiges Konto haben)

1. Gehen Sie zum Stammordner, klicken Sie auf die Schaltfläche Auschecken und erstellen Sie Arbeitsordner für Auftraggeber. Jetzt können Sie Dateien hinzufügen.
2. Nach dem Extrahieren der Projektdateien können Sie diese in einem lokalen Verzeichnis auf Ihrem Computer bearbeiten.

Nachdem Sie Änderungen an den Dateien vorgenommen haben, klicken Sie in der Symbolleiste auf die Schaltfläche Einchecken, um sie zu speichern. Sie können die Änderungen einsehen und mit Kommentaren versehen - das ist eine gute Idee, denn Sie wissen in Zukunft genau, woran Sie gearbeitet haben, welche Änderungen vorgenommen wurden und halten die anderen Projektbeteiligten auf dem Laufenden.

Ihr Kunde sollte auch jederzeit mit der Arbeit mit Revisionen beginnen können, indem er das Revisionsprotokoll oder den Änderungsverlauf öffnet - dann können Sie bei Bedarf zu zurückkehren vorherige Version für jede Datei separat. Nachdem Sie nun mit den grundlegenden Konzepten vertraut sind, ist die Dokumentation

Hallo Habr. Ich beschloss, ein Thema zu berühren, das in vielen Artikeln abgenutzt war, genauer gesagt, um die weitgehend nicht standardmäßige (ich würde sagen, nicht sortierte) Verwendung von Versionskontrollsystemen (im Folgenden als VCS bezeichnet) zu beschreiben. Liebe Programmierer, lassen Sie uns die faulen Tomaten verstecken und vorbeigehen, denn dieser Artikel ist nichts für Sie. Ja, Sie alle haben bereits alle Feinheiten der Arbeit von Git, SVN, CVS gelernt und kennen viele andere Schlagworte. Lassen Sie uns Normalsterbliche mit allen Vorteilen der Nutzung von SLE vertraut machen.
Unter dem Schnitt lade ich alle ein, die SLE kennenlernen möchten, sowie alle, die auf die eine oder andere Weise mit sich schnell ändernden Daten umgehen.

Warum wird es benötigt

Ich selbst bin Student einer Technischen Hochschule und arbeite fast ständig mit Dokumenten (Texte, Bilder, Zeichnungen) und verändere diese drei (zehn, hundert) mal am Tag. Manchmal stellt sich heraus, dass die in der letzten Woche vorgenommenen Änderungen storniert und im Stand von vor einer Woche in die Dokumente zurückgeführt werden müssen. Nun, wenn es nicht viele Änderungen gäbe, können in diesem Fall fünfzig Striche auf Strg + Z helfen. Wenn jedoch in dieser Woche mehr oder weniger aktiv mit dem Dokument gearbeitet wurde, ist es einfach nicht möglich, den Status „vor einer wichtigen Änderung vor einer Woche“ wiederherzustellen. Dies erfordert eine Kopie des Dokuments zum Zeitpunkt „vor einer wichtigen Überarbeitung“ sowie ein Dutzend weitere Kopien „vor einer weiteren wichtigen Überarbeitung“, „vor einer fragwürdigen Überarbeitung“ und „vor einer Bearbeitung, die höchstwahrscheinlich abgebrochen werden muss“. “. Grundsätzlich ist dieser Ansatz möglich und wird von vielen praktiziert. Bis vor kurzem habe ich selbst wichtige Versionen von Dateien aufbewahrt und sie mit den Präfixen "date_time" gespeichert und war anscheinend zufrieden. Der Vorteil dieser Methode ist die Einfachheit, der Nachteil ist das "Aufquellen" von Arbeitsordnern und die Unannehmlichkeiten bei der Verwendung. Und wenn der erste irgendwie zu bewältigen ist (groß Festplatte und 7zip), dann musste etwas umständlich gemacht werden.

Was kann man dagegen tun oder was ist SLE

Wir ziehen einen Absatz aus Wikipedia heraus: "Version Control System (vom English Version Control System, VCS oder Revision Control System) - Software, die die Arbeit mit sich ändernden Informationen erleichtert. Das Versionskontrollsystem ermöglicht es Ihnen, mehrere Versionen desselben Dokuments zu speichern, wenn nötig, kehren Sie zu mehr zurück frühe Versionen, bestimmen, wer und wann diese oder jene Änderung vorgenommen hat und vieles mehr." Es ähnelt dem Funktionsprinzip von Wikipedia selbst - alle Versionen von Artikeln mit allen Änderungen stehen zum Studium zur Verfügung.
Daher ist die Verwendung von VCS in einer Situation, in der Sie viele Dateiversionen speichern müssen, das, was Sie brauchen. Die Vorteile dieses Ansatzes sind die einfache Handhabung und die Einsparung von freiem Speicherplatz durch die sogenannte Delta-Komprimierung (wenn nicht die Dateien selbst in verschiedenen Versionen gespeichert werden, sondern sich von Version zu Version ändern, was die Menge der gespeicherten Daten reduziert). Lass es uns versuchen.

Was sind SLE

Dieselbe Wikipedia schlägt vor, dass SLEs zentralisiert und verteilt sind, groß und klein, mit oder ohne Schnickschnack. Daran interessiert uns nicht sonderlich, da wir (zumindest zunächst) nur einen Teil der SLE-Funktionalität nutzen werden. Wir werden genau diese Funktionalität berücksichtigen.
Fast alle VCSs sind eine Art Speicher, der alle Versionen der Dateien speichert, mit denen wir arbeiten. Hier muss klargestellt werden, dass die Version der gespeicherten Dateien meistens vom Benutzer bestimmt wird. Wir haben, sagen wir, ein Dutzend kleinere Änderungen vorgenommen und beschlossen, dass es an der Zeit war, die Ergebnisse unserer Aktivitäten im Repository zu speichern. Eine Analogie kommt mir zum periodischen Drücken von Strg + S in den Sinn, mit dem einzigen Unterschied, dass auf diese Version der Datei in Zukunft zugegriffen werden kann. Natürlich können Sie dem Repository auf einen Schlag so viele Versionen hinzufügen, wie Sie möchten. eine große Anzahl Dateien. Diese Aktion wird auf einfache Weise "Commit" oder "Commiting Changes" genannt.
Sie können jederzeit eine neue Datei hinzufügen oder eine vorhandene Datei zum Repository löschen (dies ist das geschickt genannte Repository), und das VCS wird sich "merken", wann und was wir hinzugefügt / entfernt haben. Und dank Kommentaren in Commit's kann man auch beschreiben, warum dieser Commit tatsächlich durchgeführt wird ("hier ein wenig Spielerei hinzugefügt" / "evtl. das gewünschte Stück von dort gelöscht").
Als wir endlich verstehen, dass es Zeit für uns ist, zur Version von vor einer Woche zurückzukehren, haben wir die ganze Geschichte der Änderungen. Und hier können wir wählen, was zu tun ist. Wenn Sie das gewünschte Stück aus der alten Datei kopieren und einfügen müssen aktuelle Version- Entpacken Sie einfach die alte Datei aus dem Speicher und kopieren Sie die erforderliche davon. Wenn es notwendig ist, komplett zurückzusetzen und mit der alten Version weiterzuarbeiten, kommt uns erneut SLE zu Hilfe - Sie können zur früheren Version zurückkehren und einen sogenannten neuen Zweig ("Zweig") erstellen, wobei Sie alles beibehalten, was wir " aufgegeben", indem Sie zu den Versionen von vor einer Woche zurückkehren. So kann die Versionshistorie eines Projekts grafisch als Baum dargestellt werden – von „Roots“ (der Anfang des Projekts) bis zu „Branches“ (erfolgreiche und fehlgeschlagene Bearbeitungen). Darüber hinaus kann ein "Zweig" künstlich erstellt werden, zum Beispiel für den Fall, dass wir zwei verschiedene Versionen aus den gleichen Quelldateien entwickeln - in der ersten arbeiten wir an einigen Kugeln, in der zweiten - an anderen. Außerdem, falls die Arbeitsdateien Textdokumente(und in einigen anderen) ist es möglich, verschiedene Zweige zu einem zusammenzuführen - das sogenannte "Merge". Stellen wir uns nun vor, dass mehrere Personen an einem Projekt arbeiten und jeder mit seiner eigenen "Kugel" beschäftigt ist. Ein gemeinsames Repository vereinfacht in diesem Fall die Entwicklung erheblich.

Von der Theorie in die Praxis oder der Einstieg in SLE

Ich hoffe, ich habe Sie davon überzeugt, dass die Verwendung von SLE gut ist. Es bleibt nur noch zu lernen, wie man SLE verwendet. Das werden wir tun.
Es gibt verschiedene Versionskontrollsysteme, die sich in verschiedenen Aspekten ihrer Verwendung voneinander unterscheiden. Da uns die Feinheiten der Bedienung verschiedener Systeme (zumindest zunächst) nicht interessieren, konzentrieren wir uns auf die einfachsten und freundlichsten davon. Meiner bescheidenen Meinung nach ist ein solches System seltsamerweise Mercurial - "ein plattformübergreifendes verteiltes Versionskontrollsystem, das für" effektive Arbeit mit sehr großen Code-Repositorys "mit grafische Shell SchildkröteHg. Das System kann unter Windows, Linux und Mac OS X betrieben werden.
Ich werde gleich reservieren, dass ich beschreibe, wie man mit dem System in Windows arbeitet. Wer Linux beherrscht, wird es nicht schwer haben, alles analog zu studieren.
Außerdem lernen wir parallel zu arbeiten mit kostenloses Hosting Mercurial-Repositorys - bitbucket.org, notwendig, wenn Sie nicht alleine an einem Projekt arbeiten oder, was sehr praktisch ist, über das Internet auf alle Versionen des Projekts zugreifen möchten. Im Grunde ist es ein praktischer Dropbox-Ersatz, wenn Sie es schon einmal verwendet haben.
Installieren Sie zunächst Mercurial + TortoiseHg von tortoisehg.bitbucket.org.
Dieses System funktioniert in der Konsole, also schreiben wir einige *. bat-Datei für typische Operationen.
Alle Operationen werden mit dem Befehl hg ausgeführt. Ohne Parameter aufgerufen, listet es die wichtigsten Befehle auf.
Das Repository ist ein beliebiges Verzeichnis, das wir gewählt haben (ich verwende den Ordner "C:\project\"), in dem alle Dateien unseres zukünftigen Projekts gespeichert werden sollen. Natürlich verbietet niemand, mehrere Repositorys auf einem Computer zu haben.
Damit das System "versteht", dass wir ein Repository erstellen möchten, führen wir den Befehl aus:
hg init c: \ Projekt
Danach wird der Ordner „c:\project\“ erstellt, falls er nicht zuvor erstellt wurde und der Ordner „c:\project\.hg\“, in dem Mercurial alle Serviceinformationen speichert.
Wir erinnern uns sofort daran, dass wir nicht nur ein lokales Repository auf unserem Computer haben möchten, sondern auch ein Remote-Repository, in das wir alle unsere Änderungen pushen (oder, wie die cleveren Leute sagen, Änderungen in ein Remote-Repository „pushen“, von der Englisches „Push“). Gehen Sie dazu auf bitbucket.org, registrieren Sie sich und erstellen Sie unser erstes Repository (Repositorys - Neues Repository erstellen). Geben Sie dem Repository einen Namen (ich nenne es aus Gründen der Übersichtlichkeit remote_project) und klicken Sie auf Repository erstellen.
Jetzt haben wir zwei Repositorys - ein lokales im Ordner „c:\project\“ und ein Remote-Repository unter „bitbucket.org/your_account_name/remote_project/“, wobei your_account_name bei der Registrierung bei bitbucket angegeben wird, remote_project ist das Repository Name, der bei der Erstellung ausgewählt wurde.
Um die Erkundung fortzusetzen, müssen wir etwas in unser lokales Repository legen. Erstellen Sie einfach darin (in meinem Fall - im Ordner „c:\project\“) eine beliebige Datei Ihres zukünftigen Projekts oder kopieren Sie Ihr aktuelles Projekt dorthin.
Nun müssen wir Mercurial streng genommen sagen: „Wir haben die und die Dateien und ein paar neue Ordner zum Projektordner hinzugefügt“, dafür steht der Befehl „hg add“ zur Verfügung. Ein anderer Ansatz ist jedoch bequemer - beim nächsten Commit werden wir Mercurial anweisen, alle neu erstellten Dateien aus dem Projektordner zu holen und die gelöschten zu vergessen, es ist viel einfacher, als "hg add c: \ project \ new_document" auszuführen .doc“ jedes Mal, wenn Sie ein neues Dokument erstellen“.
Kommen wir also zu unserem ersten Commit. Es wird durch den folgenden Befehl ausgeführt:
hg commit –A –m „Kommentar zum Commit“
Schauen wir uns alles der Reihe nach an. Der Befehl sollte eingegeben werden, wenn wir uns im Repository befinden (d. h. wir müssen zuerst „cd c: \ project“ ausführen). Die Option -A ist erforderlich, damit Mercurial neu erstellte Dateien abholen kann (siehe oben), die Option -m ermöglicht es Ihnen, dem Commit einen Kommentar hinzuzufügen. Diese Kommentare werden angezeigt, wenn Versionen (oder Changesets) in TortoiseHg und auf der Projektseite auf bitbucket.org angezeigt werden. Es ist sehr wichtig, aussagekräftige Kommentare abzugeben, damit Sie später nicht leiden und sich daran erinnern, wann diese oder jene Bearbeitung vorgenommen wurde.
Jetzt enthält unser Repository die erste Version unseres Projekts. Alle weiteren Commits werden auf die gleiche Weise ausgeführt, nachdem wir entschieden haben, dass es an der Zeit ist, die aktuelle Version zu speichern.
Der festgeschriebene Commit kann mit dem Befehl in das Remote-Repository gepusht werden:
hg push https://bitbucket.org/your_account_name/remote_project
In diesem Fall müssen Sie sich auch in dem Ordner befinden, der dem Repository entspricht. Nach Eingabe des Befehls werden Sie nach dem Namen und Passwort unseres Kontos auf bitbucket.org gefragt, damit Sie diese nicht bei jedem Push eingeben müssen, kann der Befehl durch Folgendes ersetzt werden:
hg push hg push https: // your_account_name: [email protected]/your_account_name/remote_project
Da wir alle Befehle in eine *.bat-Datei hämmern, wird das Passwort in diesem Fall im Klartext gespeichert, was ein gewisses Sicherheitsrisiko darstellt, aber für mich akzeptabel ist.
Der Einfachheit halber erstellen wir die Dateien commit.bat, push.bat und commit & push.bat in der Direct-Reach-Zone mit folgendem Inhalt:
[Inhalt der Datei commit.bat]
WENN!% 1 ==! gehe zum Ausgang1
cd C: \ Projekt
hg commit -A -m "% *"
gehe zum Ausgang0
: Ausfahrt1
echo "KEIN KOMMANDOZEILEN-ARG!"
: Ausgang0
Diese Datei, die mit Argumenten aufgerufen wird, schreibt das Projekt fest und fügt die Argumente dem Commit-Kommentar hinzu. Beispiel: Wir führen „commit.bat my first commit“ aus und erhalten ein Commit mit dem Kommentar „my first commit“. In FAR ist es dafür bequem die Kombination Strg + Enter zu verwenden.
[Inhalt der Datei push.bat]
cd C: \ Projekt
hg push https: // your_account_name: [email protected]/your_account_name/remote_project
Diese Datei wird an das Remote-Repository übertragen.
[Inhalt der Datei commit & push.bat]
WENN!% 1 ==! gehe zum Ausgang1
cd C: \ Projekt
hg commit -A -m "% *"
gehe zum Ausgang0
: Ausfahrt1
echo "KEIN KOMMANDOZEILEN-ARG!"
: Ausgang0
ruf ./push.bat
Diese Datei, die mit Argumenten aufgerufen wird, führt einen sequentiellen Commit und Push des Projekts durch, einschließlich der Argumente im Commit-Kommentar.
Außerdem empfehle ich für kleine Zwischen-Commits, eine Datei commit_date_time.bat zu erstellen:
[Inhalt der Datei commit_date_time.bat]
cd C: \ Projekt
hg commit -A -m "% DATE%% TIME%"
Diese Datei wird mit dem aktuellen Datum und der aktuellen Uhrzeit als Kommentar übertragen, was oft praktisch ist.
Jeder entscheidet individuell über die Häufigkeit von Commits und Pushs, je nach Intensität und Komplexität der vorgenommenen Bearbeitungen. Es wird jedoch empfohlen, sich an der Regel "Mehr ist besser" zu orientieren.
Durch Rechtsklick auf die Datei / den Ordner des Repositorys können Sie den Repository Explorer (TortoiseHg - Repository Explorer) starten, der alle unsere Commits mit Kommentaren dazu enthält. Dieses Fenster zeigt die Baumstruktur unseres Repositorys, von hier aus können Sie auch Commits, Pushs, Rollbacks zu früheren Versionen (Backouts) und andere Operationen durchführen.
Unter bitbucket.org/your_account_name/remote_project gibt es einen ähnlichen Satz von Änderungssätzen, und Sie können jede Version des Projekts in einem Archiv herunterladen, was manchmal sehr praktisch ist.
Im Allgemeinen denke ich, dass meine anfängliche Bekanntschaft mit Mercurial vorbei ist. Für mehr genaue Information kann kontaktiert werden unter: translate.by/you/mercurial-the-definitive-guide/into-ru/trans/

Für wen ist dieser Artikel?

Ich werde vielleicht damit enden, wo ich anfangen soll - für wen ist dieser Artikel? Die Antwort ist einfach - für diejenigen, die den Umgang mit SLE erlernen möchten. Ich habe es geschafft, mehrere Designer, Ingenieure und sogar einen Autor an SLE zu "hängen". Probieren Sie es selbst aus - dadurch können Sie Ihre Arbeit erheblich erleichtern.

P.S. In den Blog "Versionskontrollsysteme" verschoben.

Tags: Tags hinzufügen

Mischa Radionov

Was sind Versionskontrollsysteme und warum braucht man sie?

Zurückkehren zu

Stellen Sie sich eine Situation vor: Sie haben einen Entwickler beauftragt, Ihrem Online-Shop beispielsweise eine Schnellbestellfunktion hinzuzufügen. Da die Site ständig funktionieren und Einnahmen generieren muss, entscheidet sich der Entwickler, auf seinem lokalen Server zu arbeiten.

Während es funktioniert, schickte der Designer ein neues Logo ein, das Sie selbst in der Vorlage auf der Hauptversion der Site ersetzt haben. Gleichzeitig haben Sie die Schrift in den Warenbezeichnungen so verkleinert, dass alles auf den Bildschirm eines Netbooks Ihrer Kunden passt. Dann haben Sie ein paar Produktbilder aktualisiert. Zu diesem Zeitpunkt hat der Entwickler beschlossen, Ihnen einen Gefallen zu tun - in seiner Version Ihrer Site die ehrlich gesagt unnötige Funktionalität zu entfernen, die der vorherige Entwickler geschrieben hat. Wie so oft denken Sie beide, Sie hätten nichts Ernstes getan. Aber du liegst falsch.

Wenn die Entwicklerversion auf die Seite hochgeladen wird, schnappen sich alle Entwicklungsbeteiligten den Kopf. Ihre Arbeitsergebnisse werden gelöscht, Fehler liegen herum. Was das Problem ist, ist nicht klar. Hoffentlich haben Sie an dieser Stelle zumindest ein funktionierendes Backup zur Hand und verbringen im schlimmsten Fall einige Tage damit, Probleme manuell zu beheben. Wie kommt man nicht in diese Situation? Sagen wir es.

Was ist VCS?

Versionskontrollsystem (vom englischen Version Control System, VCS oder Revision Control System) - Software zur Erleichterung der Arbeit mit sich ändernden Informationen.

Und jetzt ganz einfach

Mit dem Versionskontrollsystem können Sie mehrere Versionen desselben Dokuments speichern, bei Bedarf auf frühere Versionen zurückgreifen, feststellen, wer wann eine bestimmte Änderung vorgenommen hat und vieles mehr.

Mit anderen Worten, VCS ermöglicht es mehreren Entwicklern, dieselben Dateien gleichzeitig zu ändern, ohne lokale Kopien auf ihren Computern zu erstellen. Gleichzeitig werden alle Änderungsvarianten separat gespeichert, und Sie können verschiedene Versionen derselben Datei erstellen, wobei unterschiedliche Bearbeitungen von verschiedenen Personen berücksichtigt werden. Wenn mehrere Änderungen dasselbe Fragment des Dokuments betreffen, bietet das System an, die gewünschte Option auszuwählen.

Normalerweise wird für die Arbeit mit einem Versionskontrollsystem verwendet separater Computer(Server) oder einen Internetdienst, mit dem Sie einen ähnlichen Server mieten können.

Ein einfaches Beispiel

Wenn über eins Excel-Dokument Wenn mehrere Personen arbeiten, kann nur eine Person auf die Datei zum Bearbeiten zugreifen, der Rest erhält „Nur-Lese“-Zugriff. Mit der Verwendung von VCS erhalten Sie die Möglichkeit, die Datei auf einmal und für alle zu bearbeiten. Einzige Bedingung ist, dass die Datei nach den Änderungen auf dem Server gespeichert werden muss und nicht auf dem lokaler Computer... Aber wie oben erwähnt, machen es Tools einfach und einfach, solche Aktionen durchzuführen.

Versionskontrollsystem im Studio Flag

Bei unserer Arbeit verwenden wir das Versionskontrollsystem Git. Dieses System ist eines der gebräuchlichsten VCS. Daher viel Unterstützung von der Git-Community. Der Vorteil ist auch die einfache Beherrschung des Systems, da es gibt eine große Auswahl Softwareprodukte speziell für dieses System entwickelt.

Wir verwenden ein Code-Entwicklungsprogramm namens IntelliJ IDEA. Es bietet eine IDE, d. h. eine große Funktionsbasis für Entwickler, einschließlich einer komfortablen Schnittstelle für die Arbeit mit der Versionskontrolle. So können wir, ohne das Programm zu verlassen, sehen, welche Änderungen von diesem oder jenem Entwickler an der von uns benötigten Website vorgenommen wurden. Oder lassen Sie sich von einem anderen Entwickler ändern, ohne befürchten zu müssen, Ihre Änderungen zu verlieren. Die IDEA-Schnittstelle sieht wie folgt aus:

Um Versionen zu speichern, verwenden wir Cloud-Dienst Bit Bucket. Dieser Service verfügt über eine benutzerfreundliche Oberfläche und ermöglicht Ihnen neben der Speicherung Ihrer Versionen auch die Verwaltung der Zugriffsregeln für Ihre Produkte für verschiedene Benutzer. Der Vorteil der Verwendung Cloud-Speicher ist das Fehlen von Kenntnissen über die Servereinrichtung und -administration. Sie erhalten alles aus der Box und können sofort loslegen. Alles, was Sie auf bitbucket hochladen, ist privat, d.h. Ohne Ihre Erlaubnis kann niemand anderes sehen, was Sie halten. Bitbucket-Schnittstelle:

Was bringt uns der Einsatz von VCS

• Absolutes Vertrauen, dass die Dateien, die wir vom System erhalten, immer auf dem neuesten Stand sind.
• Die Möglichkeit, die erforderliche Version von jedem Computer abzurufen, mit dem Sie eine Verbindung zum Server herstellen können.
• Beim Speichern einer Datei in VCS müssen Sie nicht daran denken, dass jemand, der mit derselben Datei arbeitet, Änderungen erneut speichert und überschreibt.
• Für Softwareentwickler ermöglicht die Nutzung des Systems auch die Annahme/Ablehnung von Änderungen, die von einem der Entwickler vorgenommen wurden.

Was bringt es unseren Kunden

Kehren wir zu der eingangs besprochenen Situation zurück. Wie wäre es mit VCS. Der Entwickler lädt seinen Code in einen separaten Branch hoch. Sie überprüfen die Änderungen und wenden sie nur an, wenn Sie sehen, dass alles in Ordnung ist. Alles ist an einem Ort gespeichert, sicher, schnell und bequem. Und bei mehreren Entwicklern kann man auf VCS gar nicht mehr verzichten.

Bitte aktivieren Sie JavaScript, um die anzuzeigen

Häufig arbeiten Entwickler in einem Team an einem Projekt, das heißt, mehrere Personen gleichzeitig können eine Datei gleichzeitig ändern. Um in solchen Fällen Verwechslungen zu vermeiden, wird ein Versionskontrollsystem verwendet, das es ermöglicht, die Historie von Projektänderungen zu speichern und bei Bedarf zu einer früheren Version zurückzukehren.

Versionierung

Um das Versionierungsproblem besser zu verstehen, betrachten Sie ein Beispiel eines Designers, der die Arbeit an einem Projekt beendet und die endgültige Version an einen Kunden gesendet hat. Der Designer verfügt über einen Ordner, in dem die endgültige Version des Projekts gespeichert ist:

Quelle / barbershop_index_final.psd

Alles ist in Ordnung, der Designer hat die Arbeit abgeschlossen, aber der Kunde hat die Bearbeitungen zurückgeschickt. Um zurückkehren zu können alte Version Projekt erstellte der Designer eine neue Datei barbershop_index_final_2.psd, nahm Änderungen vor und schickte sie an den Kunden:

Quelle / barbershop_index_final.psd barbershop_index_final_2.psd

Dies war jedoch nicht alles, als Ergebnis wuchs die Projektstruktur und begann wie folgt auszusehen:

Quelle / barbershop_index_final.psd barbershop_index_final_2.psd… barbershop_index_final_19.psd… barbershop_index_latest_final.psd barbershop_index_latest_final_Final.psd

Wahrscheinlich sind viele schon darauf gestoßen, zum Beispiel beim Verfassen von Hausarbeiten während des Studiums. In der professionellen Entwicklung ist es eine schlechte Praxis, neue Dateien für die Versionierung zu verwenden. Normalerweise haben Entwickler viele Dateien in ihrem Projektordner. Außerdem können mehrere Personen an einem Projekt arbeiten. Wenn jeder Entwickler für die Versionierung eine neue Datei anlegt und dabei den Namen der vorherigen Version leicht ändert, dann beginnt bald das Chaos im Projekt und niemand wird verstehen, welche Dateien geöffnet werden müssen.

Git

Um das Problem des Speicherns einer neuen Version von Dateien zu lösen, ist es bequem, Versionskontrollsysteme zu verwenden. Einer der beliebtesten ist Git. Git lässt sich mit dem Speichern und Laden in Computerspielen vergleichen:

• wenn ein schwieriger Kampf bevorsteht, ist es besser, vorher zu sparen;
• dazu müssen Sie einen speziellen Befehl ausführen.
• danach geht das Speichern an spezieller Ordner und enthält den Status des Spiels;
• jetzt ist es bei Bedarf jederzeit möglich, zur vorherigen Version des Spiels zurückzukehren.

SomeGame / | - spart | | - save001.sav | | - save002.sav | | … | | Ordner speichern | | - game.exe | ... Spieldateien

Die für die Ausführung der Anwendung erforderlichen Dateien werden im Arbeitsbereich gespeichert. Der Saves-Ordner enthält den Verlauf aller Spielstände. Git speichert Ihren Projektcode auf die gleiche Weise: speichert gehen zu einem Special versteckter Ordner und der Arbeitsbereich ist der Inhalt des Stammordners.

Grundlegendes Konzept

GUI

Spezielle Programme können die Arbeit mit Git und GitHub erleichtern. Solche Programme in einer praktischen Form zeigen Änderungen im Code, eine Liste von Commits und haben andere praktische Funktionen. Normalerweise ist es in solchen Programmen möglich, Standard-Git-Befehle auszuführen: Pull, Push, Commit und andere - einfach durch Klicken auf eine Schaltfläche.

In Kontakt mit

Telegramm