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?

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.

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.

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:

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

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

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.

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.

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.

Ich denke, ein verteiltes Versionskontrollsystem wird gut funktionieren. Die am häufigsten vorgeschlagenen Optionen sind Git und Mercurial (Hg). Grafische Werkzeuge können hilfreich sein, für Mercurial empfehle ich TortoiseHg .