Erste Schritte mit Subversion, Git oder einem ähnlichen Versionskontrollsystem, um einen Verlauf meiner Dateien zu erstellen? [geschlossen]

Mir ist klar, dass dies eine allgemeine Frage ist, aber ich suche nach konkreten Beispielen für Setups / Workflows, mit denen die Leute einen Versionsverlauf von bearbeiteten Dateien auf einer WordPress-Site führen. Zum Beispiel ändere ich beim Entwickeln einer Site (und sogar nach deren Fertigstellung) häufig CSS- und PHP-Dateien, kann aber nicht auf ältere Versionen dieser Dateien zurückgreifen. Für meine Zwecke ist es oft schwieriger, Änderungen an einer lokalen Entwicklungsinstallation vorzunehmen und diese Änderungen dann auf die Live-Site zu kopieren, als ich es gerne hätte. Haben Sie Vorschläge, wie Sie mit einem Versionsverwaltungstool beginnen können, um Änderungen an Dateien auf einer Live-Site zu verfolgen?

Ich bin mir nicht sicher, wie viel Sie über die Verwendung der Versionskontrolle wissen, aber ich bin kürzlich von SVN zu Git gewechselt und finde das großartig!

Es hängt jedoch davon ab, ob auf dem Server Ihrer Live-Site Git installiert ist (oder ob Sie es zulassen). Ich habe auch ein Git-Setup auf dem Live-Server, das von einem Zweig mit dem Namen "Etwas" ausgeht production. Immer wenn ich etwas lokal implementiert / repariert habe, füge ich es in den productionZweig ein, dann SSH in den Server der Live-Site und ziehe die Änderungen ein. Es ist besser, Dateien über FTP zu ziehen, wenn Sie nie wissen, ob Sie Änderungen überschreiben.

Ich würde empfehlen, etwas Zeit in das Kennenlernen von Git zu investieren (wenn Sie es noch nicht getan haben). Ich finde es viel einfacher und unkomplizierter als SVN, wenn es darum geht, viele Dateien zu ändern / hinzuzufügen (und im Gegensatz zu SVN ist es nicht dumm .svnOrdner überall ).

Ich bin auf einem Mac, es tut mir leid, wenn keines davon zutrifft, aber ich verwende Coda als Code-Editor und installiere Git über Ports (mit Porticus).

Wenn ich alles neu einrichten würde, würde ich Folgendes tun:

1. Installieren Sie Coda

2. Porticus installieren (dazu müssen Sie Ports installieren, aber auf dieser Seite finden Sie Informationen)

3. Sobald Sie Porticus installiert haben, öffnen Sie es, suchen Sie nach "git-core" und installieren Sie es.

4. Laden Sie GitX 7-5 herunter und installieren Sie es

5. Es gibt eine gute Anleitung zum Einrichten eines git Repo - up hier , aber es ist grundlegend: 1. Öffnen Sie das Terminal. 2. dorthin cd, wo sich Ihre Site befinden soll. $: mkdir mysite && cd mysite3. $: git initund das wars! Wenn Sie diesem Ordner Dateien hinzufügen, fahren Sie mit dem nächsten Schritt fort

6. Sobald Sie ein GIT-Repository lokal eingerichtet haben (siehe Artikel oben), können Sie beim Öffnen dieses Verzeichnisses in GitX Daten usw. usw. festschreiben.

Das alles auf dem Server einzurichten kann etwas schwierig sein. Ich habe einen MediaTemple- und einen Dreamhost-Account, die beide GIT aus der Box haben. Über den Link in Schritt 5 erfahren Sie, wie Sie ein Remote-Repo hinzufügen. Sie müssen dies also erst tun, wenn Sie Ihre Live-Site in die Gleichung einbeziehen möchten. Ich würde empfehlen, zuerst alles lokal zum Laufen zu bringen (im Gegensatz zu SVN benötigt GIT kein Remote-Repository, sodass Sie vorerst alles auf Ihrem Computer erledigen können).

Ich benutze SVN für die Versionskontrolle bei allem, was ich in der WordPress-Entwicklung mache. Eigentlich habe ich so angefangen, weil ich SVN für die Plug-in-Entwicklung brauchte. Als ich dort angefangen habe, war es eine natürliche Erweiterung, SVN weiterhin für Themen und benutzerdefinierte Skripte auf Client-Sites zu verwenden.

Plugins

Da Plug-Ins bereits auf dem WordPress-Server gehostet sind, checke ich ein Plug-In direkt in das /wp-content/plugins/Verzeichnis meiner lokalen WordPress-Installation aus (ich starte WAMP auf meiner Entwicklungs-Box). Dann nehme ich Änderungen an meiner lokalen Kopie vor und übergebe sie, wenn sie für die Showtime bereit ist, an das Repository. Es ist ein reibungsloser Prozess, kein Hochladen / Herunterladen und sofortige Bestätigung, dass meine Änderungen funktioniert haben.

Themen

Vor allem beim Erstellen für einen Client sind die Themen etwas anders. Ich erstelle ein lokales Repository (ich habe Rspeziell für diesen Zweck eine Partition auf meiner Festplatte) und checke das leere Repository direkt in mein /wp-content/themesVerzeichnis aus. Dann nehme ich nach Bedarf Änderungen vor und entwickle sie, bis sie fertig sind. Dabei überarbeite ich sie nach Bedarf.

Wenn ich bereit bin, das Thema auf dem Produktionsserver eines Kunden zu veröffentlichen, exportiere ich das Repository, komprimiere es und verwende die nativen Themen >> Neue Funktionen in WordPress. Dies funktioniert auch mit benutzerdefinierten Plug-Ins (die nicht von WordPress gehostet werden).

Werkzeuge

Wie gesagt, ich verwende WAMP auf meinem lokalen Computer, um eine Entwicklungsinstallation von WordPress auszuführen. Es funktioniert perfekt auf meiner Box und ermöglicht mir, so viele Instanzen von WordPress auszuführen, wie ich für ein bestimmtes Projekt benötige.

Für SVN verwende ich Tortoise SVN . Es ist kostenlos, bemerkenswert einfach zu bedienen und lässt sich in die Datei- und Befehlsstruktur von Windows integrieren. Das Aktualisieren, Festschreiben und Exportieren erfolgt durch einfaches Klicken mit der rechten Maustaste und Auswählen von Befehlsoperationen. Mit "Exportieren" können Sie den gesamten Ordner (ohne die lästigen .svnOrdner) direkt an einen beliebigen Speicherort senden. Ich exportiere häufig auf den Desktop. Das Komprimieren des Ordners erfolgt ebenfalls durch Klicken mit der rechten Maustaste, und WordPress übernimmt den Upload.

Das manuelle Übertragen von Dateien kann problematisch sein, insbesondere wenn Sie immer wieder eine Datei ändern, jedoch nicht alle. Wenn Sie stattdessen über FTP das gesamte Verzeichnis mit der Option "Alle überschreiben" durchsuchen, ist es viel einfacher, alte Dateien zu ersetzen (und Sie müssen nicht nachverfolgen, welche Änderungen vorgenommen wurden und welche nicht). Es ist wie bei der alten 5-minütigen Installation von WordPress - ersetzen Sie einfach alles durch die neue Version.

Persönlich halte ich es für eine unterhaltsame Übung, SVN / GIT zu installieren und zu verwalten, aber wenn Sie $ 15 pro Monat schwingen können, ist Beanstalk jeden Cent wert. Sie verwalten den gesamten Server für Sie. http://beanstalkapp.com/ Die FTP-Bereitstellungstools sind fantastisch. Mine stellt die Version automatisch auf meinem Staging-Server bereit, wenn ich zum Beispiel ein Commit durchführe

Eine andere Möglichkeit, eine persönliche Dateiversionierung zu erhalten, ist die Verwendung der Dropbox. Jedes Mal, wenn Sie eine Datei in Ihrer Dropbox speichern, wird die Version protokolliert und Sie können später eine frühere Version wiederherstellen. Sie und ein anderer Entwickler oder eine andere Gruppe können einen Dropbox-Ordner freigeben. Zugegeben, das erledigt keine Trunks, Merges usw., aber es macht es einem verteilten Team sehr einfach, an einer Website zu arbeiten. Sie können einfach nicht wirklich auf einmal an denselben Dateien arbeiten.

Wir behalten unsere SVN-Arbeitskopie in der Dropbox, dann lege ich die Dateien fest, wenn die Zeit zum Schreiben gekommen ist. Meine Designer werden keine Dateien festschreiben oder sich mit SVN befassen. Das ist also der Kompromiss.

Ich bevorzuge SVN, weil ich nicht alle Trunkings benötige, für die GIT so gut geeignet ist, und weil es bessere GUI-Tools von SVN gibt.

Ich mag Aptana sehr, es hat eine integrierte Subversion und Sie können sich mit FTP / SFTP einfach mit Ihrem Server verbinden und Dateien übertragen. Ein weiteres großartiges Feature ist, dass Sie ein neues PHP-Projekt erstellen und das "gesamte" WordPress einbinden Ordner (mit wp-admin, wp-includes) erhalten Sie Code-Vervollständigung in Ihren Designdateien.

In meinem Setup ist das Repo lokal.

Sie fragen nach "aber ich suche nach konkreten Beispielen für Setups / Workflows, mit denen die Leute einen Versionsverlauf von bearbeiteten Dateien auf einer WordPress-Site führen", aber Sie erwähnen auch Produkte :)

Sie erhalten oben als Antwort eine Liste von Tools und einige Best Practices, aber ich werde mich hier auf die Workflows konzentrieren: SIE SIND NICHT WORDPRESS-SPEZIFISCH:

Aber für die allgemeinen Beispiele / Setups / Workflows:

Für den Anfang: Es gibt CM-Muster, also unabhängig von Werkzeugen. Google auf CM Patterns, viele Bücher da draußen, sogar Wikis Communities, zB http://www.cmcrossroads.com/forums .

Es gibt auch Anleitungen zum Einrichten einer gültigen Stream-Strategie (Google Stream-Strategie) usw.

Ich glaube nicht, dass WordPress-Bereitstellungen im Vergleich zu CM Management etwas Besonderes sind, einschließlich der verteilten parallelen Entwicklung in großen Siebel-, SAP-, Informatica-, Java- usw. Fabriken. Es ist wirklich fast Standard.

Was meiner Meinung nach fehlt, ist, dass (noch) niemand einen CMplan für die WordPress-Entwicklung (IEEE) geschrieben hat. Sobald jemand das getan hat (werkzeugunabhängig). Die Anforderungen können, glaube ich, mit jedem Werkzeug erfüllt werden.

Ich denke, der Grund, warum der Plan nicht geschrieben wurde, ist, dass fast alle WordPress-Implementierungen immer noch von einer Person mit einem einfachen Entwicklungs-Produktions-Setup durchgeführt werden, sodass nicht mehrere Entwickler / Designer in der Erstellungsphase verschiedene Versionen bereitstellen müssen, die in der ausgeführt werden Testumgebung zum Beispiel.

Der CMP-Plan beginnt mit der Identifizierung aller CIs mit anderen Worten: Erstellen Sie eine Liste aller Arten von CIs, die in einer WordPress-Implementierung vorhanden sind, einschließlich der Apps, Plugins, Datenbank, Dokumentation, Hilfe, Inhalte, Konfigurationsdateien, Versionshinweise (!) usw. ..). Das ist ein guter Anfang. Entscheide dann, welche du unter CM bringen möchtest.

Entscheiden Sie als Nächstes, welche Ursachen Änderungen an diesen CIs haben, z. B. ein Kundenaufruf für einen Bugfix oder ein erforderliches Upgrade. Wenn es richtig gemacht wird, führt dies zu einer Situation, in der Sie das Gefühl haben, die Dinge unter Kontrolle zu haben.

Entscheidungen wie das Zusammenführen von Produktion zu Entwicklung und die Art und Weise, wie mit diesem Kapitel umgegangen wird (2 Hauptmuster hier) (natürlich sollten Sie versuchen, diese Hotfixes zu minimieren).

Suchen Sie erst später nach einem Tool, mit dem CM auf der einen Seite ausgeführt werden kann (einschließlich Versionsverwaltung als eines der Tools), und nach einem Tool für die Änderungsverwaltung auf der anderen Seite (mit dem Sie vernünftig bleiben).

Ich denke, das ist der beste Workflow für den Anfang, da, soweit ich gegoogelt habe, noch niemand das getan hat. Ich denke, sobald die erste Person einen WordPress CM-Plan (gemäß IEEE) geschrieben hat, kann jede andere WordPress-Person auf der Welt diesen Plan kopieren und Anpassungen vornehmen und die Muster in ihre Werkzeuge implementieren.

Ist das nicht zu viel Arbeit / zu schwer? Kommt darauf an, ob du eine Firma hast oder nicht. Es kann dir eines Tages viel Zeit sparen, einen guten CM-Plan zu haben.

Ich bin auf einem gemeinsam genutzten Host und kann daher SVN oder ähnliches nicht installieren. Ich verwende Mercurial zur Versionskontrolle auf meinem Heimcomputer. Ich verwende die FTP-Synchronisierung von Beyond Compare, um die lokalen und Remote-Ordner synchron zu halten.

Ich benutze git. Es ist einfach. Sie müssen nur einfache Befehle wie Klonen, Festschreiben, Drücken und Ziehen verstehen, und schon können Sie loslegen. Das ist die Grundvoraussetzung.

Wenn Sie jedoch git verwenden, um beispielsweise ein Team für die Arbeit an einem Produkt zu koordinieren, ist dies eine andere Ebene. Aber am Ende hat es sich gelohnt, git oder eine Versionskontrolle zu verwenden. Es ist realisierbar, wenn Scheiße passiert.