Basislogik auf localhost mit Quellcodeverwaltung arbeiten + Mercurial

Question

Ich bin ziemlich neu bei Mercurial - eigentlich neu an der Quelle Kontrolle

.

Ich habe Projekte auf localhost, das ist ~ / MAMP / htdocs. Ich möchte alle lokalen arbeiten. Es gibt einen Punkt, den ich bin verwirrt über:

Ich soll Repository auf einem anderen Pfad hält als meine htdocs Ich denke, so habe ich „/ Rep /“ Ordner und Ordner für jedes Projekt unter hier erstellen, und kopieren Sie alle Dateien aus htdocs Projektordnern zu Wiederholungen.

  

zum Beispiel; Project01

     

Kopieren von Dateien von ~/mamp/htdocs/project01/ zu   /reps/project01/

Aber ich arbeite an localhost (htdocs) für Dateien zu ändern, etc., so wie beziehe ich mich um diese Änderungen /reps/?

Offensichtlich einige sehr offensichtliche Punkt über Source Control ich fehle. Habe ich eine falsche Start machen?

Alle Tutorials fand ich online erfordert eine Art von Basiswissen, denke ich; keiner von ihnen erzählt von Bedeutung Nullpunkt nichts! : /

Answer 1

Der einfachste Weg, wenn Sie Ihre Dateien in ~/mamp/htdocs/project01/ bearbeiten (weil ich auch einig, dass es gut wäre, eine Art Staging-Bereich, wo Sie Ihre Änderungen, bevor sie auf dem Produktionsserver bereitstellen, aber vielleicht ist es testen konnte gerade das Ihre Maschine der Staging-Bereich ist, so ist alles in Ordnung, dann :-)) ist:

1. Installieren Mercurial
2. cd ~/mamp/htdocs/project01/
3. hg init
4. hg add *.html subdir *.css (was auch immer Sie verwalten möchten)
5. hg commit -m"initial version"

Nachdem Sie hg init getan haben, gibt es ein Repository in einem .hg dir unter ~/mamp/htdocs/project01/! Es ist nicht möglich, dies (noch zumindest) mit hg zu vermeiden: Wenn Sie Quellen in Project01 haben Sie eine Repo in Project01 haben müssen. Und es ist ausreichend, da man aus der Versionskontrolle mit nur profitieren können, dass, wenn Sie eine Datei zu ändern, können Sie es begehen und eine Log-Nachricht geben, das System zu sagen, was Sie getan haben, z. B.

• <edit> a.html
• hg status (wird Ihnen sagen, die aktuell geänderte Dateien)
• hg diff (wird Ihnen sagen, die Differenzen mit der gespeicherten Version)
• hg commit -m"what-has-changed-message" (speichert eine neue Version)

Auch wenn es nicht notwendig ist, ein weiteres Repo anderswo zu haben (zB in / Wiederholungen), wenn Sie will , zum Beispiel Ihre Daten in einer gesicherten Zone haben, dann könnte man einfach die klont ein in $ HOME:

• cd /reps
• hg clone /home/name/mamp/htdocs/project01/ project01

Welche in /reps/project01 eine exakte Kopie bekommen, was Sie getan haben: alle Änderungen und alle Log-Meldungen. Nun, wenn Sie das tun, wann immer Sie "hg commit" tun, um eine Änderung in Ihrem primären Repo zu speichern, können Sie auch "cd /reps/project01" und "hg pull" in tun müssen, um die Änderungen zu über / Wiederholungen zu übermitteln, wenn Sie es möchten, synchronisiert bleiben.

Hoffe, es ist einfach genug ..

Answer 2

Es gibt viele verschiedene Ansätze / Methoden . Hier ist, wie ich arbeite:

1. Entwicklung: Ich überprüfe (Klon in Merkurialien Fall) aus meinen Dateien auf meine 'Entwicklungsumgebung' auf sie zu arbeiten, dann begehen / push / etc. an der gleichen Stelle.

2. Nächste Etappen: Wenn ich denke, dass sie für die Prüfung Benutzer bereit sind / Produktion / oder was auch immer Ihre nächste Stufe ist, dann können Sie entweder verteilen Sie den Code als ein

   2a. Paket (könnte eine einfache zip Ihrer neuesten Dateien sein) oder

   2b. überprüfen Sie sie in das nächste Stadium Verzeichnis aus.

3. Andere Verbräuche: Wenn Sie ein komfortables Arbeiten mit den wichtigsten Nutzungsszenarien sind, dann sollten Sie andere betrachten Revisionskontrolle Nutzungen wie Tagging Verzweigung und Zusammenführen

Answer 3

Sie sollten in der Regel halten Sie Ihre VCS (Version Control System) und seine Dateien getrennt von Ihrer Produktion Web-Server-Umgebung (das ist, was ich schließen Sie bitten die Erwähnung von htdocs gegeben).

Viele (zumindest alte Zeit) Web-Systeme haben einen Staging-Bereich, wo Sie das Material aus dem Quellsystem zu kopieren, die Sie sorgfältig einen zweiten (nicht öffentlich zugänglich) Web-Server überprüfen können. Wenn Sie sicher sind, dass der Code korrekt ist, können Sie es in der Produktion bewegen.

Dieses Szenario hat drei Bereiche:

• Arbeits (Entwicklung) Bereich mit VCS, etc; vielleicht erreichbar über noch einen anderen Web-Server).
• Staging-Bereich (keine VCS, kein öffentlicher Zugang, Prüfung und Validierung)
.
• Produktionsbereich (kein VCS, den Zugang der Öffentlichkeit).

Es klingt ein bisschen, als ob Sie diese drei sind conflating - ein gängiges Szenario in meiner begrenzten Erfahrung. Auch wenn Sie ohne den Staging-Bereich zu tun entscheiden, müssen Sie Ihre Entwicklungs- und Produktionssysteme trennen. Und die VCS (Mercurial) im Arbeitsbereich verwendet wird.