2 lokale Webserver Änderungen transportieren ?

[Klaus1]

Hallo,

vermutlich stehe ich nur extrem auf dem Schlauch...

Ich habe 2 lokale Webserver. Der eine soll mir als Entwicklungsserver dienen, der andere als Produktivserver. Damit möchte ich auf dem einen Server in Ruhe entwickeln können ohne dass ich die Arbeit auf dem Produktivsystem störe. Ein zweiter Kollege soll nun auch noch mitarbeiten und seinerseits entwicklen können.

Gibt es ein geeignetes Tool mit dem ich nachvollziehen kann, welche Dateien ich geändert habe, die ich dann auswählen und auf das Produktivsystem transportieren/übertragen kann? Ebenso für meinen Kollegen? Vielleicht auch noch mit einem Protokoll wer was wann geändert hat? Klasse wäre natürlich, wenn nicht nur Dateien (PHP, Javascript, Images, ...), sondern vielleicht auch Tabellen-Strukturen (nicht unbedingt Inhalte) übertragen werden könnten.

Bei SAP gibt es hierfür extra ein eigenes Transportsystem. Bei jeder Änderung im Entwicklungssystem kann ein Transportauftrag erstellt werden, an dem weitere Änderungen und auch Änderungen von Kollegen angehangen werden können. Am Ende können die Änderungen dann einfach per Klick transportiert werden.

Ich habe versucht mich bei Git einzulesen, bin damit aber ehrlich gesagt nicht klargekommen.

Gibt es sowas für Webserver?

(Aktuell ist das Produktivsystem noch Windows und das Enwicklungssystem Linux, das Produktivsystem auch mit alter DB und altem PHP etc. betrieben, aber das wird sich in Kürze ändern.)

Freue ich auf konstruktive Antworten 😀

LG Klaus

[Christian Kruse]

Hallo Klaus1,

Gibt es sowas für Webserver?

Kurze Antwort: jain. Es gibt Diff-Tools wie BeyondCompare, die Folder Sync implementieren (für Linux würde man wohl rsync benutzen).

Aber ganz ehrlich: arbeite dich in Git ein. Das löst deine Probleme, und das auch viel effektiver und sicherer als Sync-Tools. Alles andere ist Gewurschtel, das irgendwann schiefgehen muss. Wenn du mit Git nicht klarkommst, dann frag nach.

LG,
CK

[Klaus1]

Hallo Christian,

Aber ganz ehrlich: arbeite dich in Git ein. Das löst deine Probleme, und das auch viel effektiver und sicherer als Sync-Tools. Alles andere ist Gewurschtel, das irgendwann schiefgehen muss. Wenn du mit Git nicht klarkommst, dann frag nach.

Das hab ich versucht, aber vielleicht bin ich zu alt oder zu doof. Ich bin damit nicht klargekommen. Kannst Du vielleicht eine grafische Oberfläche empfehlen, mit der auch Anfänger (wie ich) starten können?

git-scm.com hatte ich schon erfolglos versucht. GitHub scheint nur mit dem Veröffentlichen auf Git-Hub zu funktionieren? Spontan habe ich noch

• Git Kraken
• SourceTree
• GitBox
• Tower2
• GitEye

gefunden, wobei wohl nur Git Kraken und SourceTree kostenlos ist (was aber kein Showstopper ist)

LG Klaus

[Christian Kruse]

Hallo Klaus1,

Das hab ich versucht, aber vielleicht bin ich zu alt oder zu doof. Ich bin damit nicht klargekommen.

Wie gesagt: frag nach.

Kannst Du vielleicht eine grafische Oberfläche empfehlen, mit der auch Anfänger (wie ich) starten können?

Ich mag das von dir erwähnte Tower.

Aber vielleicht lies doch erstmal ein Tutorial über git? Auf den ersten Blick erscheint mir z.B. dieses hier brauchbar.

LG,
CK

[Klaus1]

Hallo Christian,

Wie gesagt: frag nach.

Das fängt schon damit an, dass ich nach irgendeinem Account gefragt werde. Ich habe Tower installiert und ich werde als erstes gefragt, ob ich GitHub, Bitbucket, GitLab etc. verwenden möchte. Bei allen muss ich irgendwelche Account-Informationen angeben. Welche Account-Information? Muss ich bei einem der Online-(Cloud?)-Anbieter zwingend einen Account anlegen, damit ich quasi Offline ausschließlich bei mir lokal (internes Netz) mit 2 Servern arbeiten kann? Oder kann ich das auch einfach abbrechen?

Wie wird dann später gearbeitet werden? Erstelle ich je Server ein Repository und kann diese dann abgleichen oder muss ich erstmal alle Daten auf dem Entwicklungssystem löschen, dann ein Repository auf dem Produktiv anlegen und die Daten werden beim Auschecken/Pullen/Clonen oder was auch immer rüberkopiert?

LG Klaus

[Christian Kruse]

Hallo Klaus1,

Wie gesagt: frag nach.

Das fängt schon damit an, dass ich nach irgendeinem Account gefragt werde. Ich habe Tower installiert und ich werde als erstes gefragt, ob ich GitHub, Bitbucket, GitLab etc. verwenden möchte. Bei allen muss ich irgendwelche Account-Informationen angeben.

Naja, dass sag doch „nein“ 😀 die Verwendung von Github & co ist doch nicht notwendig. Es soll nur die üblichen Developer-Bedürfnisse erfüllen. Und die sind nunmal in den meisten Fällen „ich brauche Github.“

Oder kann ich das auch einfach abbrechen?

Ja.

Wie wird dann später gearbeitet werden? Erstelle ich je Server ein Repository und kann diese dann abgleichen oder muss ich erstmal alle Daten auf dem Entwicklungssystem löschen, dann ein Repository auf dem Produktiv anlegen und die Daten werden beim Auschecken/Pullen/Clonen oder was auch immer rüberkopiert?

Der übliche Git-Workflow ist, dass du ein Repository pro Projekt hast. Dort machst du deine Änderungen und übergibst sie an git (du machst einen commit). Es bietet sich an hier möglichst kleinteilig zu arbeiten, denn das System bietet dir eine vollständige Historie seit dem ersten Commit. Und je kleinteiliger du arbeitest, desto gezielter kannst du Änderungen auch rückgängig machen (das nennt sich dann revert). Sprich du fasst Änderungen logisch zusammen. Statt einem großen Commit, der alle Änderungen des Tages enthält, machst du mehrere kleine Commits, etwa einen der eine Änderung am Model macht, einen, der einen Bugfix implementiert, usw, pp.

Wenn du die Änderungen dann veröffentlichen möchtest, schiebst (push) du die Änderungen in dein zentrales Repository. Und von dort kannst du es dann auf die einzelnen Server ziehen (pull).

Wirklich, lies dir mal die verlinkten Tutorials durch 😀

LG,
CK

[Klaus1]

Hallo,

ich habe mir testweise GitKraken installiert, einmal weil offenbar kostenlos und die Oberfläche sah auf den ersten Blick gut aus.

Mir ist aber auch mit den Tutorials und Tutorial-Videos nicht klar, wie ich jetzt starten soll.

Ich habe 2 Server, auf die ich beide direkten Zugriff über ein gemapptes Laufwerk habe (Windows-Freigabe und Linux-Samba). Beide Server haben natürlich schon vorhandene Dateien im jeweiligen Verzeichnis /srv/www/htdocs.

Natürlich existiert erstmal noch kein Repository. Ich habe also erstmal ein neues lokales (Test-)Repository auf einem Server erstellt. Dabei wurde aber ein neues leeres Verzeichnis angelegt. Ich habe schonmal herausgefunden, dass ich die Dateien von Hand reinkopieren kann. Diese werden vom GitKraken erkannt und ich kann sie "stagen" und danach "committen".

Das Repository wird mir als Master angezeigt. Wofür das "Stagen" jetzt benötigt wird, weiß ich nicht, denn Änderungen werden sofort in das Verzeichnis geschrieben, sobald ich speichere. Neue Dateien werden sofort im Verzeichnis angelegt.

Dann habe ich zweites (Test-)Repository angelegt und das als Remote-Repository angegeben.

Ich hab noch nicht verstanden, welches jetzt mein Produktiv- und welches mein Entwicklungssystem ist

Der Versuch, Dateien vom Remote zu holen (Pull?) schlägt mit einem "no merge base found" fehlt. Ebenso bei einem Push.

Irgendie dachte ich, ich müsste einfach nur Quelle und Ziel, Master und Slave, Produktion und Entwicklung angeben. Das war wohl viel zu einfach gedacht ?!

LG Klaus

[Auge]

Hallo

Mir ist aber auch mit den Tutorials und Tutorial-Videos nicht klar, wie ich jetzt starten soll.

Ich habe 2 Server, auf die ich beide direkten Zugriff über ein gemapptes Laufwerk habe (Windows-Freigabe und Linux-Samba). Beide Server haben natürlich schon vorhandene Dateien im jeweiligen Verzeichnis /srv/www/htdocs.

Grundsätzliches Vorgehen:

Auf dem Testserver hast du ein Repository. Hier entwickelst du neue Features, behebst Fehler, testest den veränderten Code ganz normal mit deinem Editor oder einer IDE und commitest die einzelnen Änderungen in die Historie des Repositories. Der jeweils aktuelle Code liegt ganz normal in seinen Verzeichnissen, Git kümmert sich nur um die Historie der Änderungen.

Auf dem Produktivserver gibt es eine Kopie des Repositories. Es befindet sich im Dateisystem direkt in den Verzeichnissen, in denen das Programm werkelt. Mit git pull holst du den aktuellen Stand des Repositories vom Entwicklungsserver, wenn du einen dortigen Stand für stabil hältst. Damit befindet sich ein synchronisierter Stand automatisch in der Produktion.

Ich habe also erstmal ein neues lokales (Test-)Repository auf einem Server erstellt. Dabei wurde aber ein neues leeres Verzeichnis angelegt.

Normalerweise sagt man Git, ein bestehendes Verzeichnis sei nun ein Git-Repository. So braucht man keinen neuen Verzeichnisbaum, sondern benutzt die bestehende Struktur.

Ich habe schonmal herausgefunden, dass ich die Dateien von Hand reinkopieren kann. Diese werden vom GitKraken erkannt und ich kann sie "stagen" und danach "committen".

Wenn du stattdessen die bestehende Verzeichnisstrutur zum Repository gemacht hättest, würdest du dir das umherkopieren ersparen. Dateien und Änderungen zu stagen und zu commiten bliebe natürlich deine Aufgabe.

Das Repository wird mir als Master angezeigt. Wofür das "Stagen" jetzt benötigt wird, weiß ich nicht, denn Änderungen werden sofort in das Verzeichnis geschrieben, sobald ich speichere. Neue Dateien werden sofort im Verzeichnis angelegt.

Mache dir klar, dass ein Versionsverwaltungssystem „echte“ Änderungen im „echten“ Dateisystem bemerkt und auf deinen Befehl hin dokumentiert. Mehr (grundsätzlich) nicht, auch wenn man zum Beispiel mit git -rm verzeichnis/datei.name Dateien löschen kann. Das kann man aber auch ganz normal im Dateinamager tun. Git bekommt es mit und bietet dir die Dokumentation dieses Vorgangs an.

Tschö, Auge

[Klaus1]

Hi,

Auf dem Testserver hast du ein Repository.

Das noch nicht existiert. Das muss ich ja erst noch anlegen. Man erstellt also immer zu allererst das Repo für den Testserver?

Auf dem Produktivserver gibt es eine Kopie des Repositories.

Aktuell haben beide rein File-technisch denselben Stand. Muss ich hier erstmal alle Dateien löschen und dann einen Clone erzeugen?

Normalerweise sagt man Git, ein bestehendes Verzeichnis sei nun ein Git-Repository. So braucht man keinen neuen Verzeichnisbaum, sondern benutzt die bestehende Struktur.

Genau diese Funktion habe ich (zumindest beim GitKraken) bisher nicht finden können.

Wenn du stattdessen die bestehende Verzeichnisstrutur zum Repository gemacht hättest, würdest du dir das umherkopieren ersparen.

Zur Not würde ich dann htdocs in htdocs_temp umbenennen, dann ein Repo für htdocs erstellen und alles von htdocs_temp nach htdocs rüberschieben. Ich hatte testweise (um mir nicht versehentlich irgendetwas zu zerstören) ein Test-Verzeichnis genommen.

Nach meinem jetzigen Verständnis bin ich wie folgt vorgegangen:

• Ein neues Repo auf dem Testserver erstellt
• Ein neues Repo auf dem Produktivserver erstellt
• Dem Test-Repo das Repo vom Prod als Remote eingetragen
• In beiden Verzeichnissen eine unterschiedliche Datei reinkopiert
• auf beiden Seiten gestaged und committed
• Push / Pull probiert: Fehlermeldung: "no merge base found"
• verzweifelt

Über die Dokumentationen komme ich einfach nicht weiter.

LG Klaus

[dedlfix]

Tach!

Auf dem Testserver hast du ein Repository.

Das noch nicht existiert. Das muss ich ja erst noch anlegen. Man erstellt also immer zu allererst das Repo für den Testserver?

Das ist sinnvoll. Wenn du mit einem zentralen Repo arbeitest, kannst du auch zuerst dieses erstellen (als bare repo) und es auf deinen Arbeitsplatz clonen. Oder du machst ein Push von deinem zuerst erstellten Arbeits-Repo in das zentrale Bare-Repo.

Auf dem Produktivserver gibt es eine Kopie des Repositories.

Aktuell haben beide rein File-technisch denselben Stand. Muss ich hier erstmal alle Dateien löschen und dann einen Clone erzeugen?

Clones wollen sich eigentlich in leere Verzeichnisse entpacken. Es ist aber kein Problem, es irgendwo in einem temporären Verzeichnis zu entpacken und dann nur das .git-Verzeichnis in das bereits bestehende Arbeitsverzeichnis zu verschieben, und den temporären Rest zu löschen.

Normalerweise sagt man Git, ein bestehendes Verzeichnis sei nun ein Git-Repository. So braucht man keinen neuen Verzeichnisbaum, sondern benutzt die bestehende Struktur.

Genau diese Funktion habe ich (zumindest beim GitKraken) bisher nicht finden können.

Zur Not geht immer, ein leeres Repository irgendwo zu erstellen und das .git-Verzeichnis in das bereits bestehende Arbeitsverzeichnis zu verschieben.

Wenn du stattdessen die bestehende Verzeichnisstrutur zum Repository gemacht hättest, würdest du dir das umherkopieren ersparen.

Zur Not würde ich dann htdocs in htdocs_temp umbenennen, dann ein Repo für htdocs erstellen und alles von htdocs_temp nach htdocs rüberschieben.

In der Richtung geht es auch.

Ich hatte testweise (um mir nicht versehentlich irgendetwas zu zerstören) ein Test-Verzeichnis genommen.

Nach meinem jetzigen Verständnis bin ich wie folgt vorgegangen:

• Ein neues Repo auf dem Testserver erstellt
• Ein neues Repo auf dem Produktivserver erstellt
• Dem Test-Repo das Repo vom Prod als Remote eingetragen

Ich würde ein zentrales Repo erstellen und das als Remote in beiden eintragen. Beziehungsweise auf dem Produktivserver einen Clone aus dem zentralen ziehen, dabei sollte das Remote gleich mit eingetragen werden (oder es ist mein Client, der das für mich macht).

• In beiden Verzeichnissen eine unterschiedliche Datei reinkopiert
• auf beiden Seiten gestaged und committed
• Push / Pull probiert: Fehlermeldung: "no merge base found"
• verzweifelt

Nun hast du zwei separate Repos und nicht Kopien vom selben. Das zentrale muss für den ersten Push immer leer sein, dann wird es zur Kopie deines Arbeitsrepos.

---

Als Empfehlung kann ich noch Gogs anpreisen. Das ist ein System ähnlich zu Github und im Gegensatz zu Gitlab deutlich einfacher einzurichten. Mit diesem kann man die zentralen Repos recht gut verwalten. Wenn du also nicht nur mit dem einen arbeiten möchtest, sondern auch noch andere Projekte hast, ist das sicher einfacher, als die zentralen Repos in Handarbeit zu managen.

dedlfix.

[Klaus1]

Guten Morgen!

Wenn du mit einem zentralen Repo arbeitest, kannst du auch zuerst dieses erstellen (als bare repo) und es auf deinen Arbeitsplatz clonen. Oder du machst ein Push von deinem zuerst erstellten Arbeits-Repo in das zentrale Bare-Repo.

Womöglich bin ich zu doof, aber ich verstehe es noch immer nicht so richtig.

Ich habe bisher keine einzige Datei auf meinem lokalen Arbeitsplatz. Ich habe auf meinem PC 2 Laufwerksmappings. Laufwerk T: zeigt auf auf das /srv/www/htdocs vom Testserver (Entwicklungsserver), Laufwerk P: zeigt entsprechend auf das Produktivsystem. Mein Kollege ebenso.

Wo erstelle ich dann sinnvollerweise das Bare-Repo?

Wenn ich vorher ein Repo von Laufwerk T gemacht habe, kann ich doch erst dann Pushen, wenn das Bare-Repo als Remote angegeben wurde oder?

Ich würde ein zentrales Repo erstellen und das als Remote in beiden eintragen. Beziehungsweise auf dem Produktivserver einen Clone aus dem zentralen ziehen, dabei sollte das Remote gleich mit eingetragen werden (oder es ist mein Client, der das für mich macht).

Das werde ich direkt probieren, sobald mir klar ist, wo das zentrale Repo liegen soll.

Nun hast du zwei separate Repos und nicht Kopien vom selben. Das zentrale muss für den ersten Push immer leer sein, dann wird es zur Kopie deines Arbeitsrepos.

Ok, das erklärt die Fehlermeldung mit dem "no merge base found"

LG Klaus

[dedlfix]

Tach!

Ich habe bisher keine einzige Datei auf meinem lokalen Arbeitsplatz. Ich habe auf meinem PC 2 Laufwerksmappings. Laufwerk T: zeigt auf auf das /srv/www/htdocs vom Testserver (Entwicklungsserver), Laufwerk P: zeigt entsprechend auf das Produktivsystem. Mein Kollege ebenso.

Wo erstelle ich dann sinnvollerweise das Bare-Repo?

Ein Bare-Repo ist eins ohne Arbeitsverzeichnis. Man nimmt es nur, um eine Kopie des Repos zu verwalten, ohne Änderungen am Inhalt vorzunehmen. Das kommt also an eine zentrale Stelle, und wird auf den Repos mit Arbeitsverzeichnis als Remote eingetragen. Jeder Entwickler pusht seine Commits dorthin und aktualisiert darüber seine Kopie mit den Änderungen der anderen. Konsumenten holen sich dort den neuesten Stand (oder den vom Produktiv-Branch, aber Brachen ist wieder eine Geschichte für sich, die für den ersten Anfang nicht benötigt wird).

Wenn ich vorher ein Repo von Laufwerk T gemacht habe, kann ich doch erst dann Pushen, wenn das Bare-Repo als Remote angegeben wurde oder?

Jedes Repo ist an sich gleichwertig. Dass das eine kein Arbeitsverzeichnis hat, spielt für das Synchronisieren von Repos keine Rolle. Es spielt auch keine Rolle, in welcher Reihenfolge sie eingerichtet werden, nur müssen sie leer sein, wenn sie mit einem anderen verbunden werden sollen, das schon Daten hat. Aber ich erklär das mal an meiner üblichen Vorgehensweise. (Man kann auch anders vorgehen, viele Wege führen nach Rom). Zuerst erstell ich mir ein lokales Repo mit Arbeitsverzeichnis. Da kommen meine ersten Commits rein, wenn schon welche da sind. Dann leg ich ein zentrales Repo als Bare an. In meinem Fall ist das meist auf einer Gogs-Installation, kann aber genausogut mit Kommandozeile oder jedem anderen Verwaltungsprogramm erfolgen. Dieses zentrale Repo wird nun als Remote bei meinem anderen eingetragen und ich kann nun mit Push die Commits vom lokalen in das zentrale kopieren. Alle weiteren Repos werden direkt als Clone von diesem zentralen erzeugt und sind dann bereits fertig konfiguriert (zumindest mit meinen Tools, ob die CLI das gleich als Remote konfiguriert, weiß ich nicht).

Das werde ich direkt probieren, sobald mir klar ist, wo das zentrale Repo liegen soll.

Auf irgendeiner Server-Maschine. Das kann zur Not auch der produktive Server sein. Und wenn man noch mehr Not hat, legt man das mit Arbeitsverzeichnis im VHost des Webservers an. Besser wäre aber, ein Bare-Repo als zentrales zumindest irgendwo abseits des VHosts zu haben. Dazu ein weiteres mit Arbeitsverzeichnis im VHost.

Es ist auch sehr empfehlenswert, darauf zu achten, dass das .git-Verzeichnis nicht via Web-Request befragt werden kann. Da liegen teilweise sensible Daten drin, die man nicht veröffentlichen möchte.

dedlfix.

[Klaus1]

Neuer Versuch:

• Ein leeres Master-Repo erstellt (P:\masterrepo)
• Ein leeres Dev-Repo erstellt (T:\test\dev)
• Ein leeres Prod-Repo erstellt (P:\test\prod)
• In Dev und Prod habe als Remote den Master eingetragen.
• Im Dev-Repo eine neue Datei erstellt (test.php)

Aus dem Dev-Repo heraus den Push probiert Ich erhalte die Meldung: "refs/heads/master" is behind "refs/remote/masterrepo/master". Update your branch by doing a Pull.

Bei einem Pull kommt wieder: No merge base found!

Beim Pull gibt es noch mehrere Optionen:

• Fetch all
• Pull (fast-forward if possible) = Default
• Pull (fast-forward only)
• Pull (rebase)

Was mache ich nur falsch?

LG Klaus

[Christian Kruse]

Hallo Klaus1,

Neuer Versuch:

• Ein leeres Master-Repo erstellt (P:\masterrepo)
• Ein leeres Dev-Repo erstellt (T:\test\dev)
• Ein leeres Prod-Repo erstellt (P:\test\prod)

Da liegt schon der Fehler. Du sollst nicht je Server ein Repo erstellen. Du erstellst ein Repo pro Projekt, wo das liegt ist im Grunde egal. Bei mir liegt es für die Arbeit auf einem Server in der Firma. Alle anderen Kopien sind via git clone geklont worden, etwa so:

Server 1:

mkdir myproject
cd myproject
git init .

Workstation:

git clone git@server1:/path/to/myproject
cd myproject

Production ist dann auch nur ein Clone:

cd /var/www
git clone git@server1:/path/to/myproject www.myproject.de

Bei einer Änderung auf der Workstation machst du dann einmal git commit und git push:

cd myproject
git commit -a
git push

zum Veröffentlichen auf Production dann z.B.

git pull

LG,
CK

[Klaus1]

Hallo CK,

was ist jetzt bei Dir Server 1 und die Workstation? Ich habe ja aktuell bereits 2 quasi identische Server. Auf dem einen entwickle ich und wenn ich fertig bin, schiebe ich von Hand die Dateien auf den Produktiv-Server Beide haben also schon alle Daten.

Wenn ich das richtig verstanden habe, lege ich irgendwo auf irgendeinem beliebigen Server mein Projekt an. Nehmen wir mal an, ich würde das Projekt auf dem Entwicklungs-Server anlegen (Laufwerk T:)

Dann wäre das:

T:
cd \myprojekt
git init .

Danach erstelle ich jeweils einen Clone vom dev und vom prod?

T:
cd /srv/www/htdocs
git clone T:/myproject dev

und

P:
cd /srv/www/htdocs
git clone T:/myproject prod

Wenn ich jetzt eine Datei verändert habe, diese committe und pushe, wird dann die Datei auf T:/srv/www/htdocs verändert? Und mit einem Push dann die Datei auf dem Laufwerk P: ?

(Da mir Git bisher völlig neu ist, schlage ich mich im Moment mit GUI-Versionen rum, in der Hoffnung, dass diese die gleiche Terminilogie verwenden werden). Aktuell: GitKraken

LG Klaus

[dedlfix]

Tach!

Wenn ich das richtig verstanden habe, lege ich irgendwo auf irgendeinem beliebigen Server mein Projekt an. Nehmen wir mal an, ich würde das Projekt auf dem Entwicklungs-Server anlegen (Laufwerk T:)

Dann wäre das:

T:
cd \myprojekt
git init .

Danach erstelle ich jeweils einen Clone vom dev und vom prod?

Nicht "vom" sondern "für". Am besten nimmst du ein Repository als das maßgebliche. Ich würde da das zentrale (bare) nehmen. Alle anderen lokalen Repos (Clone) werden mit diesem zentralen Repo synchronisiert.

Wenn ich jetzt eine Datei verändert habe, diese committe und pushe, wird dann die Datei auf T:/srv/www/htdocs verändert? Und mit einem Push dann die Datei auf dem Laufwerk P: ?

Nein, der Push synchronisiert deine lokalen Änderungen mit dem zentralen Repo. Auf der Produktionsmaschine musst du ein Pull (oder Fetch und anschließendes Checkout) machen, um den aktuellen Stand zu bekommen. Das passiert nicht automatisch.

Weiterhin hast du ja noch Mitarbeiter. Auch die müssen bei ihrem lokalen Clone ein Pull (oder Fetch mit Checkout) machen, um die Änderungen der anderen zu bekommen. Mitunter müssen dabei Merge-Konflikte gelöst werden, wenn sie bereits weitergearbeitet haben. Solche Konflikte treten auch auf, wenn sie lokale Änderungen commitet haben und diese Commits dann zum zentralen Repo zu pushen versuchen, wenn in der Zwischenzeit andere ebenfalls Commits erstellt und gepusht haben.

dedlfix.

[dedlfix]

Tach!

Was mache ich nur falsch?

Die einfachste Vorgehensweise ist, das zentrale (Bare-)Repo zuerst zu erstellen und die lokalen Kopien als Clone von diesem zentralen zu ziehen. Dann wissen die Repos quasi, dass sie zusammengehören.

Ich kann dir nicht genau sagen, wie du die einzeln angelegten zusammenführst. Wenn ich das bei mir so mache, also zuerst ein Arbeits-Repo und dazu ein Bare anderenorts, dann macht mein "Git Extensions" alles notwendige, dass die beiden zueinander finden.

dedlfix.

[Auge]

Hallo

Um das mal auseinanderzunehmen und die letzten Klarheiten zu beseitigen.

Wie gesagt: frag nach.

Das fängt schon damit an, dass ich nach irgendeinem Account gefragt werde. Ich habe Tower installiert und ich werde als erstes gefragt, ob ich GitHub, Bitbucket, GitLab etc. verwenden möchte. Bei allen muss ich irgendwelche Account-Informationen angeben. Welche Account-Information? Muss ich bei einem der Online-(Cloud?)-Anbieter zwingend einen Account anlegen, damit ich quasi Offline ausschließlich bei mir lokal (internes Netz) mit 2 Servern arbeiten kann?

Git ist zuerst einmal ein lokal (auf deinem Rechner) funktionierendes System. Viele Entwickler, die mit Git arbeiten, arbeiten aber mit anderen zusammen an Projekten und für den gemeinsamen Zugriff auf die Daten eines Repositories eignet sich numal eine zentral gehaltene Kopie des Repos. Die kann man lokal auf einem eigenen Server betreiben (zum Beispiel mit GitLab ^[1]) oder das an einen Dienstanbieter wie GitHub, GitLab ^[1:1] oder BitBucket auslagern.

Um die Konfiguration des Zugriffs auf externe Ressourcen (nicht auf deinem Rechner) zu erleichtern, bieten Git-Clients halt an, die Zugangsdaten zentral für alle Repositories zu verwalten.

Oder kann ich das auch einfach abbrechen?

Ich kenne Tower selbst nicht, denke aber, dass du diesen Konfigurationsschritt bedenkenlos abbrechen kannst.

Tschö, Auge

---

1. GitLab gibt es als Downloadpaket, das man auf einem eigenen Server installieren kann und ebenso als vom Hersteller betriebener Dienst auf deren Servern analog zu GitHub. ↩︎ ↩︎

[1unitedpower]

Kannst Du vielleicht eine grafische Oberfläche empfehlen, mit der auch Anfänger (wie ich) starten können?

Wenn du VSCode als Editor benutzt, kann ich dir GitLens empfehlen.

git-scm.com hatte ich schon erfolglos versucht.

git-scm.com ist sehr technisch geschrieben und wendet sich eher an fortgeschrittene Git-Nutzer. Anfängern empfehle ich immer die Tutorials von Atlassian.

[dedlfix]

Tach!

Gibt es ein geeignetes Tool mit dem ich nachvollziehen kann, welche Dateien ich geändert habe, die ich dann auswählen und auf das Produktivsystem transportieren/übertragen kann? Ebenso für meinen Kollegen?

Git.

Auswählen, was zu übertragen ist, muss nicht sein. Das Git kann auch auf der Produktivmaschine installiert werden und man kann da den aktuellen Stand auschecken.

Vielleicht auch noch mit einem Protokoll wer was wann geändert hat?

Git. Es gibt auch grafische Oberflächen, die ohne Kommandoeingabe auskommen.

Klasse wäre natürlich, wenn nicht nur Dateien (PHP, Javascript, Images, ...), sondern vielleicht auch Tabellen-Strukturen (nicht unbedingt Inhalte) übertragen werden könnten.

Was sind Tabellen-Strukturen? SQL-Code in einer Textdatei? Dann Git.

Ich habe versucht mich bei Git einzulesen, bin damit aber ehrlich gesagt nicht klargekommen. Gibt es sowas für Webserver?

Ich weiß ja nicht, was dein Problem damit ist. Vielleicht musst du die Dokumentation zu Git erstmal einfach so lesen, ohne deine Anforderungen mit Git zu vergleichen. Für den täglichen Betrieb braucht man meist nur Einchecken, Commit, Auschecken. Und wenn man ein zusätzliches zentrales Repository hat, dann auch Push und Pull. Die Sache mit dem Branchen kann man sich für später aufheben. Mergen wäre noch wichtig, wenn man an denselben Dateien arbeitet, um Konflikte aufzulösen.

(Aktuell ist das Produktivsystem noch Windows und das Enwicklungssystem Linux, das Produktivsystem auch mit alter DB und altem PHP etc. betrieben, aber das wird sich in Kürze ändern.)

Freue ich auf konstruktive Antworten 😀

Nimm Git. Läuft auf beiden genannten Systemen.

dedlfix.