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.

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