Wie benutzt man die Versionskontrolle?


19

Ich entwickle eine Website in PHP in localhost und lade sie nach Fertigstellung der Module in die Cloud hoch, damit meine Freunde sie alpha testen können.

Während ich mich weiter entwickle, habe ich viele Dateien und verliere den Überblick über die Dateien, die ich bearbeitet oder geändert habe usw. Ich habe von einer Art Versionskontrolle gehört, um all diese zu verwalten, bin mir aber nicht sicher, wie sie funktioniert.

Meine Frage lautet also: Steht mir ein einfacher Weg / Dienst / eine Anwendung zur Verfügung, um alle Bearbeitungen / Änderungen / neuen Dateien nachzuverfolgen und die Dateien während der Entwicklung der Website zu verwalten. Sobald ich mit einem Modul fertig bin, möchte ich es in die Cloud hochladen (ich verwende Amazon Cloud Service). Wenn etwas mit den neuen Dateien passiert, möchte ich möglicherweise zur alten Datei zurückkehren. Und vielleicht sehe ich mit ein oder zwei Klicks die Dateien, die ich seit dem letzten Upload bearbeitet oder geändert habe?


5
Es gibt viele Vorschläge, welches Versionskontrollsystem zu verwenden ist, und um ehrlich zu sein, alle sind besser als Ihre derzeitige "manuelle" Vorgehensweise.
Johan

Antworten:


28

Das Softwarekonfigurationsmanagement , zu dem auch die Versionskontrolle gehört, ist etwas komplexer als das Verfolgen von Änderungen an Dateien, obwohl Sie mit Sicherheit damit beginnen können. Lesen Sie jedoch die Wikipedia-Artikel, die oben zusammen mit Joel Spolkys Tutorial zu Mercurial verlinkt sind .

Wählen Sie zunächst eine der Optionen Mercurial, GIT oder Bazaar in dieser Reihenfolge aus und installieren Sie sie zusammen mit den Tools für Ihre IDE und Ihr Betriebssystem (ich bevorzuge Mercurial mit HGE für Eclipse).

  1. Initialisieren Sie ein Repository aus Ihrem Arbeitsverzeichnis ( hg init mit Mercurial).
  2. Entscheiden Sie, welche Dateien und Verzeichnisse Sie verfolgen möchten und welche nicht. Die allgemeine Regel lautet, keine Dateien zu verfolgen, die von Compilern und anderen Tools generiert wurden.
  3. Verwenden Sie den Befehl, um die Dateien und Verzeichnisse zum Repository hinzuzufügen ( hg add for Mercurial).
  4. Teilen Sie dem Tool die Muster für die Dateien mit, die Sie nicht verfolgen möchten (bearbeiten Sie .hgignore für Mercurial).
  5. Führen Sie ein Commit durch, um die Originalversionen zu verfolgen ( hg ci ).
  6. Führen Sie nach jedem logischen Meilenstein ein Commit durch, auch wenn es sich um einen kleinen handelt.
  7. Fügen Sie beim Erstellen neue Dateien hinzu.
  8. Wiederholen Sie die letzten beiden.
  9. Sichern Sie Ihr Arbeitsverzeichnis und das Repository so häufig wie möglich.

Mit Ihren Dateien im Repository können Sie die Unterschiede zwischen zwei Versionen einer Datei oder eines Verzeichnisses oder das gesamte Projekt ( hg diff ) kennen, den Änderungsverlauf ( hg hist ) anzeigen und Änderungen rückgängig machen ( hg up -r) ).

Es ist eine gute Idee, das Repository vor dem Veröffentlichen Ihres Codes mit einem Tag ( hg-Tag ) zu versehen, damit Sie auf einfache Weise genau zu dem zurückkehren können, was Sie für Änderungen oder Vergleiche veröffentlicht haben.

Wenn Sie mit einer anderen Entwicklungslinie experimentieren möchten, tun Sie dies in einem einfachen Zweig, indem Sie das Hauptrepository ( hg clone ) klonen und nicht zurückschieben, bis das Experiment abgeschlossen ist. Es ist so einfach wie ein anderes Arbeitsverzeichnis für das Experiment.

Wenn es sich bei dem Test um eine neue, aktualisierte Version handelt, klonen Sie und verzweigen Sie dann ( hg branch ), damit Sie alle Kopien der Repositorys auf dem neuesten Stand halten können, ohne dass ein Test den anderen beeinträchtigt.

Linus Torvalds (der sich in seinen Projekten mit Zehntausenden von Dateien und Millionen von Codezeilen befasst) sprach bei Google darüber, warum das Tool nicht CVS, SVN oder eines der vielen kostenlosen und kommerziellen Tools sein kann ; es ist sehr sehenswert.


1
Ich bevorzuge auch Mercurial. Ich mag die Unterstützung in Netbeans, weil während des Codierens jede Zeile angezeigt wird, die sich seit Ihrem letzten Commit geändert hat. Außerdem werden neue / geänderte / unveränderte Dateien im Produktbaum farblich gekennzeichnet. Welche klingt wie wäre es für den OP hilfreich sein: I lose track of which file I've edited or changed. HGE darf das auch, ich habe es nicht benutzt.
JD Isaacks

1
+1 für die Beschreibung des Prozesses sowie einen Teil der Verwendung von Tools, um dies zu tun.
Donal Fellows

Als .xcodeprojNebenfrage: Wird die Datei, die Xcode für iOS-Projekte verwendet, als Hinweis für Mercurial angesehen, dass sie ignoriert werden soll, oder ist es wichtig, die Datei synchron zu halten?
Kevin Yap

1
@ Kevin Ich kenne Xcode nicht, aber die neuesten IDEs und Tools verfügen über separate Konfigurationsdateien für das gesamte Projektmaterial (Sprach- und Bibliotheksversionen, Regeln für die Codeformatierung, Abhängigkeiten usw.) und Benutzereinstellungen (Verzeichnisse, in denen ich das Material ablege, Kontrollleiste) Layout, Skins, Schriftgröße, persönliche Unterschrift). Ersterer kann in das Repository aufgenommen werden, wenn das Team zustimmt. Letzteres sollte nicht enthalten sein, da ein Update aus dem Repository Ihre Einstellungen mit denen anderer überschreiben würde, was schnell ärgerlich und kontraproduktiv wird.
Apalala

1
@ John: NetBeans macht das für jedes VCS, das es unterstützt. Zu diesem Zeitpunkt ist dies nur eine grundlegende Funktion von IDEs.
Mike Baranczak

13

Ich kann Git nur empfehlen. Erfahren Sie hier mehr darüber: https://lab.github.com/

Wenn Sie Git nicht mögen, gibt es andere Lösungen für die Versionskontrolle. Sie könnten SVN auschecken.


1
Als alltäglicher Benutzer von Git möchte ich hinzufügen, dass es extrem einfach und intuitiv ist, die wesentlichen Befehle zu erlernen. Und die Unterstützung dafür ist großartig, damit Sie nicht verloren gehen, wenn Sie Hilfe suchen. Ich habe SVN verwendet, aber es war nicht so einfach für mich, aber es könnte für viele Benutzer in Ordnung sein.
Muhammad Usman

1
+1 Bedenken Sie auch: Menschen entscheiden sich dafür, von svn (ein VCS) zu git (ein DVCS - d = verteilt) zu wechseln, aber nicht von GIT zu SVN (durch Wahl).
Michael Durrant

7

Sind es nur Sie? Verwenden Sie ein DVCS

So kontraintuitiv es auch klingt, ein verteiltes Versionskontrollsystem (mercurial, git, bazaar) ist anfangs besser als ein zentralisiertes System (svn, cvs). Warum ?, Sie installieren es auf Ihrem Computer und führen Ihr Repository lokal aus, und das wars. Auf einem zentralen System wie svn müssen Sie Ihren Client und einen Server einrichten. Anschließend müssen Sie eine Verbindung zu einem Server herstellen, um Ihre Änderungen zu speichern.

Mit einem DVCS sind Sie das lokale Repository, und wenn Sie möchten, können Sie einen Dienst wie bitbucket.org oder github.com verwenden.

Meiner Meinung nach ist mercurial ein freundlicheres und gleichermaßen fähiges DVCS.

Gibt es andere? Verwenden Sie ein DVCS!

Es gibt zahlreiche Vorteile bei der Verwendung eines DVCS für die Zusammenarbeit mit einem Team. Das wichtigste im Gegensatz zu einem zentralisierten System besteht darin, dass es keine Commit-Rennen gibt. Dies liegt daran, dass das Repository eines jeden Einzelnen technisch gesehen ein Zweig ist und Sie Ihren Zweig teilen Änderungen, die in diesen Zweigen vorgenommen werden, werden für Sie zusammengeführt, und Sie bemerken es nicht einmal. Dies bedeutet, dass Sie statt eines Versionsverlaufs wie diesem Leute haben, die ihre Arbeit auf einer geraden Linie ausführen:

Bildbeschreibung hier eingeben

Am Ende haben Sie so etwas, bei dem jeder nur Ad-hoc-Commit ausführt:

Bildbeschreibung hier eingeben

Jeder kümmert sich nur um seine eigene Arbeit während der Versionsverwaltung (dh nicht um das Festschreiben) und nicht um die Verbindung zu einem Server, nur um das Festschreiben.

Viel Glück


1
+1 Sehr schöne Beispiele! Sie sollten bearbeiten, um die fehlenden Schmerzen in komplexen Zusammenführungsbäumen mit modernen Werkzeugen hervorzuheben.
Apalala

5

Um es kurz zu machen, es gibt viele Alternativen, unter denen Subversion (SVN) und Git am beliebtesten zu sein scheinen (daher ist es am einfachsten, Lösungen im Web zu finden).

Sie unterscheiden sich beide. SVN ist einfacher, aber Git erfordert nicht, dass Sie zuerst einen Server haben - Sie können die Version lokal steuern.

Angenommen, Sie haben Linux und möchten Git verwenden:

  1. Installieren Sie Git
  2. Gehe in das Verzeichnis und führe den Befehl 'git init' aus
  3. Erfahren Sie, wie Sie Dateien hinzufügen, Änderungen überprüfen, festschreiben ...
  4. ... und für fortgeschrittenere Aufgaben (Überprüfen von Protokollen, Zurücksetzen von Änderungen, Ignorieren von Dateien, Erstellen von Verzweigungen, Zusammenführen, Erstellen und Verwenden von Remotes, Verwenden von Submodulen, Verwenden der SVN-Unterstützung usw.).

Hoffe das hilft dir beim Start.


1
Für SVN ist kein Server erforderlich, das Repository muss sich jedoch in einem anderen Verzeichnis als dem Arbeitsverzeichnis befinden. SVN und CVS werden im Allgemeinen nicht mehr für Tools wie GIT und Mercurial verwendet, für die keine Netzwerkverbindung für die tägliche Arbeit und kein zentrales Repository für die kollaborative und verteilte Softwareentwicklung erforderlich ist.
Apalala

Denken Sie nicht, dass dies tatsächlich mit dem Erstellen eines SVN-Repository-Servers auf localhost identisch ist? Sie müssen das zentrale Repository konfigurieren und warten. Wenn Sie Ihre Dateien verschieben, müssen Sie sicherstellen, dass das SVN-Repository weiterhin verfügbar ist (denken Sie nicht einmal daran, das gesamte zentrale Repository jedes Mal zu kopieren, wenn Sie Dateien auf einen anderen Computer verschieben). Ich denke auch nicht, dass Subversion veraltet ist (ich spreche aber nicht über CVS) - es ist nur zentralisiert und in einigen Fällen wäre es eine bessere Idee, die Zentralisierung durchzusetzen.
Tadeck

Apalala, eine Frage: Wie geht Mercurial mit Informationen um, die der Benutzer speziell geändert hat? In Git können Sie es ändern und die Änderung als eine andere Person festschreiben, wodurch Unordnung entsteht (es gibt eine Funktion, mit der Commiter von Submitter unterschieden werden kann, die jedoch nicht offensichtlich genug ist). Hat Mercurial dieses Problem im Zusammenhang mit der verteilten Versionskontrolle gelöst?
Tadeck

2
@Tadeck So funktionieren Mercurial und GIT meines Erachtens nicht. In diesen Fällen ist eine einzelne Person für das verantwortlich, was in ein Repository gelangt, sei es durch Commits, Pulls oder Patches. Wenn in verteilten Repositorys jemand Push-Berechtigungen hat, vertrauen Sie ihm bereits von ganzem Herzen. Linus Torvalds erklärt es in diesem Vortrag gut: youtube.com/watch?v=4XpnKHJAok8
Apalala

@Tadeck In Bezug auf SVN habe ich es häufig verwendet und dachte schließlich, es sei keine Verbesserung gegenüber CVS (das zumindest reine ASCII-Repositorys hat und ausgereift genug ist, um sie niemals zu beschädigen). Auch dies erklärt Torvalds in dem Video, das ich zuvor verlinkt habe, sehr gut. Die Unfähigkeit, offline zu arbeiten, und die Unfähigkeit, zusammenzuführen, führen dazu, dass alte SCM-Tools veraltet sind.
Apalala

2

Wie Apalala vorschlägt, empfehle ich, hginit auszuchecken . Da Sie mit der Versionskontrolle noch nicht vertraut sind, können Sie die erste Seite überspringen. Das sollte dir ein gutes Intro geben, danach kannst du auf SO posten, wenn du spezielle Fragen hast.


0

Ich werde der Mehrheitsmeinung widersprechen und Subversion empfehlen. Subversion ist einfach zu bedienen und erledigt alle Aufgaben, die Einzelpersonen und kleine Teams benötigen. Es ist ein ausgereiftes Produkt, daher wird es von jeder IDE unterstützt. Ja, es hat nicht alle Funktionen von Git. (Ich habe Mercurial noch nie verwendet, daher werde ich nicht darüber sprechen.) Die meisten Entwickler benötigen diese zusätzlichen Funktionen jedoch nicht.

Mehrere Repositories? Ich bin sicher, dass es legitime Verwendungszwecke für diese gibt, aber ich bin ihnen nie begegnet.

Lokale Commits ohne Netzwerkzugriff durchführen zu können? Das ist schön zu haben, wenn Sie mehrere diskrete Änderungen vornehmen und nicht auf den Repository-Server zugreifen können - aber ehrlich, wie oft passiert das?

Git erleichtert das Verzweigen und Zusammenführen. Aber für ein Ein-Mann-Team ist das keine so große Sache.

Für etwas auf der Skala des Linux-Kernels - ja, verwenden Sie Git. Für den Rest von uns ist Subversion gut genug.


Downvoting. Die Funktionen von Git, die nicht in SVN enthalten sind (z. B. einfache Verzweigung und einfaches Zusammenführen), sind sowohl bei kleinen als auch bei großen Projekten hilfreich und möglicherweise sogar unerlässlich.
Marnen Laibow-Koser

1
@ MarnenLaibow-Koser Ja, das war damals meine Meinung, aber nachdem ich Git mehrere Jahre professionell eingesetzt habe, muss ich dir zustimmen.
Mike Baranczak

Ausgezeichnet! Sie werden assimiliert. : D
Marnen Laibow-Koser

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.