Einzelentwickler-GIT-Workflow (Übergang von einfachem FTP)


11

Ich versuche zu entscheiden, ob ein Wechsel zu VCS für mich sinnvoll ist. Ich bin ein einzelner Webentwickler in einer kleinen Organisation (5 Personen). Ich denke aus folgenden Gründen an VCS (Git): Versionskontrolle, Offsite-Backup, zentrales Code-Repository (Zugriff von zu Hause aus).

Im Moment arbeite ich generell auf einem Live-Server. Ich fTP ein, nehme meine Änderungen vor und speichere sie, lade sie erneut hoch und aktualisiere sie. Die Änderungen betreffen normalerweise Themen- / Plugin-Dateien für CMS (z. B. konkrete5 oder Wordpress). Dies funktioniert gut, bietet jedoch keine Sicherung und keine Versionskontrolle.

Ich frage mich, wie ich VCS am besten in dieses Verfahren integrieren kann. Ich würde mir vorstellen, einen Git-Server auf dem Webserver des Unternehmens einzurichten, aber mir ist nicht klar, wie Änderungen an Client-Konten (normalerweise VPS auf demselben Server) übertragen werden sollen - im Moment melde ich mich einfach mit ihren Details bei SFTP an und mache die Änderungen direkt.

Ich bin mir auch nicht sicher, was ein Repository sinnvoll darstellen würde - würde die Website jedes Kunden eine eigene bekommen?

Alle Einsichten oder Erfahrungen wären wirklich hilfreich. Ich glaube nicht, dass ich die volle Leistung von Git brauche, aber eine grundlegende Versionskontrolle und ein De-facto-Cloud-Zugriff wären wirklich nützlich.

EDIT: Ich habe es auf die beiden Optionen eingegrenzt, die am sinnvollsten erscheinen. Die erste basiert auf der Antwort von ZweiBlumen , wobei Änderungen auf dem Live-Server vorgenommen und von dort auf den (externen) Git-Server übertragen werden. Dies hat den Vorteil, dass sich an meinem Workflow nicht viel ändert (es gibt den zusätzlichen Schritt, die Festschreibungen vorzunehmen, aber ansonsten ist er identisch).

Die zweite Möglichkeit besteht darin, lokal mit XAMPP zu arbeiten und dann Änderungen vom lokalen Computer festzuschreiben. Erst wenn die Site online geht, lade ich den fertigen Artikel vom lokalen Computer auf den Webserver hoch (unmittelbar nach dem endgültigen Festschreiben an Git). Theoretisch scheint dies in Ordnung zu sein, aber wenn die Site danach Änderungen erfordert und ich sie auf dem Live-Server vornehme (wie ich es normalerweise tue), muss ich die geänderten Dateien in meinem lokalen Repo manuell kopieren und diese Änderungen dann auf die übertragen Git Server. Dies scheint übermäßig komplex zu sein und ist möglicherweise eine zu große Abweichung von meinem aktuellen Workflow.

Alles in allem werde ich Option 1 ausprobieren und sehen, wie es mir geht.


1
Bei git (oder einem anderen verteilten VCS) ist zu beachten, dass alle Repositorys zumindest technisch gesehen Peers sind: Ihr lokales Repository ist genauso "echt" wie das auf dem Live-Server oder dem Backup-Repository. Es sind Ihre Workflow-Richtlinien, die ihnen Struktur verleihen. Wenn Sie also wirklich weiterhin primäre Arbeit auf dem Live-Server leisten möchten, können Sie ...
Comingstorm

Danke, das ist gut zu wissen. Die inhärente Flexibilität von Git macht es schwierig, einen "Best Practice" -Startpunkt zu finden - das ist eine Stärke des POV eines erfahrenen Benutzers, aber wohl eine Schwäche eines Noobs!
Melat0nin

Antworten:


3

Was ich mache (mit Subversion, aber auch mit Git), ist, alles in ein Subversion-Repository zu übertragen, aber offensichtlich nach Bedarf in Projekte, Zweige und Tags aufzuteilen. Ich checke dann diese Repositorys auf dem Live-Server aus. Wenn ich also auf meinem Entwicklungscomputer eine Änderung vornehme und diese in das Repository übertrage, muss häufig nur die ausgecheckte Kopie auf dem Live-Server aktualisiert werden, um die Änderungen live zu übernehmen. Der zusätzliche Bonus ist, dass ich, wenn ich eine schnelle Lösung auf dem Live-Server vornehmen muss, diese vom Server in das Repository übertrage und die Arbeitskopie auf meinem Entwicklungscomputer aktualisiere.

Ich bin mir sicher, dass es andere Möglichkeiten gibt, dies zu verwalten, aber ich finde das recht einfach und bin in genau der gleichen Situation wie Sie: Einzelner Entwickler in einer kleinen Organisation (4 Personen).


1
Danke für deine Antwort! Bedeutet das, dass Sie den Snapshot auf Ihren lokalen Computer ziehen, Änderungen vornehmen und festschreiben und dann eine Pull-Anforderung vom Live-Server ausführen (durch SSHing in)? Was ist, wenn die Änderung wirklich klein ist? Führen Sie einen lokalen Webserver für die Entwicklung aus? (Ich konnte diesen Prozess für einfache CSS-Änderungen nicht durchlaufen. Ich würde verrückt werden!)
melat0nin

1
Bei einer geringfügigen CSS-Änderung würde ich die Änderung direkt auf dem Server vornehmen und diese Änderung dann vom Server in das Repository übertragen. Wenn ich ernsthafter an der Site arbeiten muss, aktualisiere ich die Site auf meinem Entwicklungscomputer mit der neuesten Version der Site aus dem Repository. Ich denke, es spielt keine Rolle, wo Sie die Änderung vornehmen (Server oder Entwicklungsmaschine), solange Sie sie in das Repository übertragen.
ZweiBlumen

Welche Tools verwenden Sie dafür? FTP, um die Datei direkt auf dem Server zu ändern, dann wird im Hintergrund eine SSH-Sitzung geöffnet, um ab und zu die Commits für den Git-Server durchzuführen?
Melat0nin

1
Ja, das ist es im Grunde. Tatsächlich benutze ich Subversion. Wir haben Websites auf Windows- und Linux-Servern. Nehmen Sie unter Windows I-Remotedesktop die CSS-Änderung vor und schreiben Sie sie mit TortoiseSVN fest. Unter Linux verwende ich eine SSH-Sitzung und vim, um die Änderungen vorzunehmen (aber Sie können Ihre Änderungen auch per FTP übertragen, denke ich).
ZweiBlumen

Ich bin Ihrem Vorschlag gefolgt, auf dem Server zu bearbeiten und dann von dort aus über SSH zu verpflichten, was ich jetzt seit einigen Tagen mache. Scheint wirklich gut zu funktionieren, danke!
Melat0nin

2

Es ist ziemlich einfach, einen post-updateHook zu erstellen , der das git archiveWebserver-Datenverzeichnis automatisch aktualisiert ( aus Sicherheitsgründen wird der Export mit bevorzugt), wenn Sie zu einem bestimmten Zweig wechseln.

Lassen Sie also irgendwo ein Git-Repository mit einem solchen Hook einrichten (aus Sicherheitsgründen würde ich es auf einen anderen Server als das Web stellen). Sie benötigen natürlich einen Testserver, um größere Änderungen zu testen, die sich entweder auf Ihrem lokalen Computer befinden oder durch Drücken auf einen anderen Zweig aktualisiert werden können. In beiden Fällen können Sie es für einfache Rechtschreib- und CSS-Korrekturen umgehen, indem Sie einfach Commit und Push ausführen.


1

Ich würde diese Schritte befolgen:

  1. Richten Sie den Remote-Server mit einem geeigneten öffentlichen / privaten Schlüsselpaar für Remote-Push / Pull ein
  2. Richten Sie zwei Zweige zum Testen und Freigeben ein
  3. Entwickeln Sie lokal mit einer Testumgebung in der Testbranche
  4. Wenn Sie zufrieden sind, führen Sie den Release-Zweig zusammen und drücken Sie ihn auf den Remote-Server
  5. Schließen Sie den Remote-Server an, um auf die neueste Version der Version zu aktualisieren

Richten Sie ein Repo pro Website ein, damit sie sich nicht gegenseitig überladen. Durch die separaten Zweige können Sie vermeiden, dass die aktuelle "gute" Versionssperre auf das eingestellt wird, woran Sie gerade arbeiten, was möglicherweise funktioniert oder nicht.


Verstehe ich das richtig? Es gibt zwei Server (1) für Git, (2) einen Live-Webserver und eine lokale Entwicklungsmaschine. Dev wird lokal gemacht und dann auf den Git-Server geschoben, der einen Hook zum Aktualisieren des Live-Servers hat?
Melat0nin

@ melat0nin Das ist eine Möglichkeit, es zu tun. Sie können den Live-Server auch als Cron-Job vom Git-Server abrufen lassen. Oder Sie können 2 Maschinen haben. Die lokale Entwicklungsmaschine und der Webserver für die Live-Produktion. Auf diese Weise wird das Repo von der Entwicklungsmaschine auf die Produktionsmaschine aktualisiert und bei jedem Push auf den neuesten Release-Zweig aktualisiert.
Spencer Rathbun
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.