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

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.

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).

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.

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.