Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Git Workflow Frage - Verzeichnisse & Arbeitskopie

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [Erledigt] Git Workflow Frage - Verzeichnisse & Arbeitskopie

    Habe mich erneut in das Thema Git/SCM hineingelesen und möchte es jetzt umsetzen, da der Bedarf besteht.

    Ziel:
    Auf externen (remote) Host ein Bare-Repo haben, worauf Redmine (Ist wie Trac) zugreift und Tickets automatisch mit dem entsprechenden Patch verlinkt werden.
    Nennen wir das Repo: ProjektWPTemplate

    Auf dem gleichen Server befindet sich die Live-Demo von Wordpress mit dem Template.

    Lokal arbeite ich auch offline an den Daten und habe eine Wordpressinstallation auf meinem lokalen Webserver.

    Ausgearbeitete Lösung:
    Bare-Repo auf dem Server anlegen.

    Code:
    [martha@eridanus ~]$ mkdir ProjektWPTemplate.git
    [martha@eridanus ~]$ cd ProjektWPTemplate.git
    [martha@eridanus myproject]$ git init --bare
    Repo auf meinen PC klonen (kein Bare-Repo, mit Arbeitskopie), daran arbeiten mit git add/git commit und zurückspielen via git push origin master.

    Code:
    [someuser@somehost ~]$ git clone ssh://martha@eridanus.de/home/martha/ProjektWPTemplate.git/
    [someuser@somehost ~]$ cd ProjektWPTemplate
    [someuser@somehost ProjektWPTemplate]$ echo "Irgendetwas zum add+commit" > test.txt
    [someuser@somehost ProjektWPTemplate]$ git add test.txt
    [someuser@somehost ProjektWPTemplate]$ git commit -m "initial commit"
    [someuser@somehost ProjektWPTemplate]$ git push origin master
    Fragen:

    1.)
    Im von mit genannten Projekt handelt es sich z.B. nur um ein Wordpress Theme, das unter wp/themes/meintheme lokal liegt.
    Wo sollte das geklonte Repo mit Arbeitskopie am besten lokal liegen?
    Im [ich@lokal ~], also Homeverzeichnis und dann via Symlink ein Ordner im eigentlichen documentroot/wp/themes/meintheme legen?
    Oder sollte es genau andersherum gemacht werden, das Bare-Repo in documentroot/wp/themes/meintheme geklont werden und dann im ~ Verzeichnis ein Symlink dorthin erstellen?

    Es erscheint mir sinnvoll, dass alle lokalen Git Repos in einem Verzeichnis liegen, damit sie schnell auffindbar sind.
    (Zwecks schnelleren Commit/Push würde ich mir dann ein alias lokal anlegen in .bash_profile)

    2.)
    Ebenfalls wie bei 1.), wo ist es am sinnvollsten das Git Repo auf dem remote host (externen Server) zu legen?
    Da dort ebenfalls die Kundendemo ist, die laufend aktualisiert werden sollte, sehe ich verschiedene Möglichkeiten:

    a.) Das Bare-Repo wird direkt im documentroot/kundendemo/wp/themes auf dem externen Server angelegt.
    b.) Ich lege das Bare-Repo in ~ auf dem externen Server an und setze einen Symlink im documentroot/kundendemo/wp/themes

    3.)
    Z.Zt. greife nur ich auf das Repo zu. Es ist mittelfristig absehbar, dass mehrere Benutzer es verwenden werden. Dafür werde ich Gitolite verwenden. Ist es problemlos möglich zu einem späteren Zeitpunkt, wenn der Bedarf vorhanden ist, sich darum zu kümmern oder ist der Aufwand größer und Gitolite sollte sofort am Anfang installiert/konfiguriert werden?

    4.)
    Ist es ratsam bei solch einem Projekt, die gesamte Wordpressisnstallation als Repo zu nutzen (Vorteil sehe ich z.B. durch Möglichkeit des Rückspielens von überschriebenen Dateien bei automatischen Update von Wordpress die zu inkompatibilitäten führen könnten).
    Wenn ja, wie sieht es praktisch mit Dateien wie der Datenbankkonfigurationsdatei aus, die sich unterscheidet auf lokalem und externen Server.

    5.)
    Ist das ein empfehlenswerter Workflow zur Nutzung von Git in Verbindung mit Redmine oder gibt es Verbesserungsvorschläge?

    Die Hauptfragen nochmal kurz und knackig zusammengefasst:
    Ist der von mir zusammengestellte Workflow, der, der er sein sollte um das Ziel zu erreichen?
    In welche Verzeichnisse sollte man ein lokal geklontes Repo (und auch das Bare-Repo auf dem externen Host) packen, wenn es z.B. um ein Theme geht, das ein Unterverzeichnis (wp/themes/) einer sowohl lokalen Wordpressinstallation ist (Zum Arbeiten) und auf dem remote host (Es ist ein Server, auf diesem liegtauch das Bare-Repo mit Redmine) als auch die Installation als Kundendemo liegt?

    Herzlichen Dank, für die Zeit all derjenigen, die mir helfen!


    Update1://
    Beim weiteren Google bin ich darauf gestoßen, hört sich genau nach dem an was ich brauche?!
    ...
    I assume you are trying to use Git for website publishing? ... . In short:
    You create 2 repositories on the server. One is a bare repository, just like the one you have already created, but it's outside of the public_html directory
    Other is a normal repository inside the public_html directory
    You create a post-receive hook that updates the repository inside the public_html directory whenever you push to the bare repository
    Quelle: http://stackoverflow.com/a/16161464
    Update2://
    Eine weitere Anleitung gefunden, hier auf php.de, dort wird es so beschrieben wie oben von mir gedacht, via Symlink anstatt anstatt zwei Repositories mit dem gleichen Inhalt (Wurde bei Update1:// vorgeschlagen):
    und das document root des ausgecheckten repository ist symlinked auf subdomain.domain.tld
    Quelle: http://www.php.de/php-fortgeschritte...tml#post804995


  • #2
    Zitat von dreamcatcher Beitrag anzeigen
    1.)
    Im von mit genannten Projekt handelt es sich z.B. nur um ein Wordpress Theme, das unter wp/themes/meintheme lokal liegt.
    Wo sollte das geklonte Repo mit Arbeitskopie am besten lokal liegen?
    Im [ich@lokal ~], also Homeverzeichnis und dann via Symlink ein Ordner im eigentlichen documentroot/wp/themes/meintheme legen?
    Oder sollte es genau andersherum gemacht werden, das Bare-Repo in documentroot/wp/themes/meintheme geklont werden und dann im ~ Verzeichnis ein Symlink dorthin erstellen?

    Es erscheint mir sinnvoll, dass alle lokalen Git Repos in einem Verzeichnis liegen, damit sie schnell auffindbar sind.
    (Zwecks schnelleren Commit/Push würde ich mir dann ein alias lokal anlegen in .bash_profile)
    Ich habe zwar auch einen Ordner voll mit allen möglichen Git-Repo's, aber die meisten davon Java oder C/C++/Asm. Wenn ich an einem PHP/HTML-Projekt arbeite erstelle ich das Lokale Repo gleich dort, wo ich arbeite (xampp/htdocs/projektname...). Der Grund "zwecks schnellerem Commit" ist sinnlos. Wenn du grade an deinem Projekt arbeitest ist es wohl kaum zu viel arbeit, schnell ne Kommandozeile im Projektordner zu öffnen.

    Zitat von dreamcatcher Beitrag anzeigen
    2.)
    Ebenfalls wie bei 1.), wo ist es am sinnvollsten das Git Repo auf dem remote host (externen Server) zu legen?
    Da dort ebenfalls die Kundendemo ist, die laufend aktualisiert werden sollte, sehe ich verschiedene Möglichkeiten:

    a.) Das Bare-Repo wird direkt im documentroot/kundendemo/wp/themes auf dem externen Server angelegt.
    b.) Ich lege das Bare-Repo in ~ auf dem externen Server an und setze einen Symlink im documentroot/kundendemo/wp/themes
    Das Bare-Repo gleich in wp/themes/* zu legen ist sinnlos, in einem Bare-Repo gibt es keinen Workingtree.

    Im Optimalfall erstellst du einen neuen User "git" und packst dorthin alle Repo's. Du kannst dir auch mal GitLab, das ist eine schöne Weboberfläche (in etwa wie GitHub), die die Administration erleichtert und auch schön die neusten Aktivitäten (Pushs, ...) anzeigt. Dort wird auch der User "git" genommen. Damit du live Änderungen siehst kannst du natürlich die unten im Edit genannte Möglichkeit nutzen und ein hook einrichten, um im Zielverzeichnis das Repo nochmal zu Clonen.

    Zitat von dreamcatcher Beitrag anzeigen
    3.)
    Z.Zt. greife nur ich auf das Repo zu. Es ist mittelfristig absehbar, dass mehrere Benutzer es verwenden werden. Dafür werde ich Gitolite verwenden. Ist es problemlos möglich zu einem späteren Zeitpunkt, wenn der Bedarf vorhanden ist, sich darum zu kümmern oder ist der Aufwand größer und Gitolite sollte sofort am Anfang installiert/konfiguriert werden?
    Wenn du einen eigenen User für Git erstellst dürfte das auch später kein Problem mehr sein. Aber wie gesagt, schau dir GitLab an, das regelt das alles für dich.

    Zitat von dreamcatcher Beitrag anzeigen
    4.)
    Ist es ratsam bei solch einem Projekt, die gesamte Wordpressisnstallation als Repo zu nutzen (Vorteil sehe ich z.B. durch Möglichkeit des Rückspielens von überschriebenen Dateien bei automatischen Update von Wordpress die zu inkompatibilitäten führen könnten).
    Wenn ja, wie sieht es praktisch mit Dateien wie der Datenbankkonfigurationsdatei aus, die sich unterscheidet auf lokalem und externen Server.
    Nein, definitiv nicht. Ins Repo gehört nur das Projekt. Automatische updates wird man ausstellen können nehm ich an?

    Für eigene Config-Dateien erstellst du eine Vorlage (config.php.xyz) die im Repo liegt, gleichzeitig ein .gitignore auf die eigentliche Config (config.php), sodass du nach dem Clonen die Config kopieren und anpassen kannst, und diese von Git dann einfach nicht beachtet wird (auch beim fetch/pull nicht).

    Zitat von dreamcatcher Beitrag anzeigen
    5.)
    Ist das ein empfehlenswerter Workflow zur Nutzung von Git in Verbindung mit Redmine oder gibt es Verbesserungsvorschläge?

    Die Hauptfragen nochmal kurz und knackig zusammengefasst:
    Ist der von mir zusammengestellte Workflow, der, der er sein sollte um das Ziel zu erreichen?
    Ich habe mit Redmine noch nie gearbeitet. Aber im Endeffekt kannst du dein Repo hinclonen wo du willst. Ob du es nun nach ~/repositorys/ clonst und ein Symlink erstellst oder es gleich dahin clonst wo du es brauchst ist ganz egal, mach es wie du besser damit zurecht kommst.
    ...
    I assume you are trying to use Git for website publishing? ... . In short:
    You create 2 repositories on the server. One is a bare repository, just like the one you have already created, but it's outside of the public_html directory
    Other is a normal repository inside the public_html directory
    You create a post-receive hook that updates the repository inside the public_html directory whenever you push to the bare repository
    Quelle: http://stackoverflow.com/a/16161464
    Ja, so kannst du es natürlich machen. Nochmal: Ein Bare-Repository hat KEINEN Workingtree, also alles was im geclonten Repo liegt gibt es dort nicht. Das Bare-Repository besteht ausschließlich aus dem .git-Verzeichnis, daher kannst du dieses nicht "direkt" nutzen sondern musst nochmals davon clonen.
    Zitat von nikosch
    Macht doch alle was Ihr wollt mit Eurem Billigscheiß. Von mir aus sollen alle Eure Server abrauchen.

    Kommentar


    • #3
      Danke tkausl für die ausführliche Antwort.

      Habe mir jetzt stundenlang Tutorials durchgelesen und mehrere Videos, u.A. von einem Githubmitarbeiter angeschaut (https://www.youtube.com/watch?featur...&v=ZDR433b0HJY).

      Hat sich viel währenddessen geklärt, auch dank deinen Ausführungen

      Ich kürze ab, es sind noch zwei Fragen offen:

      1.)
      Bei mir im Einsatz sind Redmine+Git.
      Um eine ACL zu verwenden (Multiuserunterstützung) stehen Gitlab oder Gitolite bereit.
      Gitlab bietet gleichzeitig ein WebUI.

      Ich kann nicht viel erkennen, das Gitlab besitzt und Redmine nicht.
      Zwei Punkte: Merging via Weboberfläche und Kommentare direkt an Zeilen in commits anhängen.

      Merging habe ich bei der Demo getestet: Nur rudimentär implementiert. Klappt nur solange die Branches im gleichen Baum sind. Wir es kniffliger und es wird aus einem anderen, nicht direkt verbundenen Baum gemerged, kommt die Meldung, man solle bitte auf die Console ausweichen. Geringer Nutzen.

      Kommentare ist eine gute Funktion.

      Frage:
      Gibt es sonst keine 'Drawbacks' wenn Gitolite vorgezogen wird, vor Gitlab?
      Ich möchte ungern zwei Webinterfaces haben, außer es bringt eine spürbare Verbesserung.
      Übersehe ich etwas? Was würdest Du empfehlen? Gitolite & Redmine oder zwei Weboberflächen (Gitlab & Redmine miteinander verknüpft), da Gitlab auf lange Sicht einen deutlichen Mehrwert bietet?

      (Hier ein Bespiel wie z.B. die Diff View aussieht bei Redmine: http://www.redmine.org/projects/redm...6&rev_to=13357)

      2.)
      Habe beim Schreiben die Lösung gerade gefunden
      http://krisjordan.com/essays/setting...eploy-with-git

      Ein fertiges Script, dass es nur klont, wenn die master branch gepusht wird und es dazu noch so klont, dass ich keinen .git Ordner im Deployment-Verzeichnis habe!
      (Das war mir wichtig)

      Großartig!
      Bleibt nur noch Frage 1

      Kommentar


      • #4
        Ich hab jetzt mal ein wenig Gegoogled. Was genau Redmine alles tut weiß ich immer noch nicht, allerdings ist Redmine so wie ich das jetzt verstanden habe eher ein Projektverwaltungstool, wobei optional auch Repositorys eingebunden werden können für automatisches Issue-Closen, Commit-Diff, usw.
        Gitlab allerdings ist eher ein Verwaltungstool für Git und die Repositorys, d.h.:
        - Rechteverwaltung per Useraccount, 4 Rechtestufen die per Repository (und per Team) vergeben werden können (Sowie "User" und "Admin" die Gitlab-weit vergeben werden (Beispielsweise: Nur lesend, auch schreibend aber nicht in den Hauptbranch, auch in den Hauptbranch, alles der vorherigen sowie Administration des Repositorys)
        - Teamverwaltung wobei einem Repository gleich ein ganzes Team zugewiesen werden kann
        - SSH-Keys können von Usern selbst eingetragen werden
        - Commit-History, Akivitäten Chronologisch aufgelistet auf dem Dashboard (Haupt-Dashboard: Aktivitäten aus allen Repositorys auf die man zugriff hat wird aufgelistet, Repository-Eigenes Dashboard: Nur Aktivitäten aus diesem Dash-Board werden aufgelistet), Datei-Blame (Welcher User hat welche Zeile geschrieben), Editieren gleich im Webpanel (mit Commit versteht sich)
        - Hooks gleich im Webpanel anlegen
        Das sind nur einige der Features.

        Natürlich hat Gitlab auch die Möglichkeit für Issue-Management, eine Wiki, Merge-Requests und Snippets (pro Repository), allerdings ist die Software primär auf das Verwalten und Administrieren des Repositorys selbst ausgelegt. Daher denke ich, dass Redmine und Gitlab auch gut zusammen verwendet werden können.

        Google bestätigt, dass die beiden auch von anderen zusammen genutzt werden: https://github.com/gitlabhq/gitlabhq/issues/97

        Wie das ganze genau abläuft kann ich dir aber nicht sagen, da ich (wie gesagt) Redmine nicht wirklich kenne.

        Merging habe ich bei der Demo getestet: Nur rudimentär implementiert. Klappt nur solange die Branches im gleichen Baum sind. Wir es kniffliger und es wird aus einem anderen, nicht direkt verbundenen Baum gemerged, kommt die Meldung, man solle bitte auf die Console ausweichen. Geringer Nutzen.
        Ich nehme an, dass im Webpanel nur Fast-Forward unterstützt wird wegen den möglichen mergeconflicts.

        Gibt es sonst keine 'Drawbacks' wenn Gitolite vorgezogen wird, vor Gitlab?
        An sich kannst du natürlich auch Gitolite nutzen, allerdings musst du dann von hand jeweils die Repositorys erstellen, die User (und ssh-keys?) eintragen, gesicherte branches einstellen (sofern gitolite das überhaupt kann), bei Mediumwechsel (Einer der Mitarbeiter will mal vom Laptop aus pushen) muss dann wieder darauf gewartet werden, bis jemand zeit hat den neuen Key im Server einzutragen, usw.
        Gehen tut es, aber es kann sehr viel Arbeit per Hand sein.

        Edit: Siehe hier für Screenshots (unter anderem auch Diff-View) von Gitlab: https://about.gitlab.com/gitlab-ce/
        Zitat von nikosch
        Macht doch alle was Ihr wollt mit Eurem Billigscheiß. Von mir aus sollen alle Eure Server abrauchen.

        Kommentar


        • #5
          Ich möchte hier auch noch Stash ins Spiel bringen. Ist zwar ein kommerzielles Produkt, doch bietet es einen ziemlich guten Funktionsumfang.
          GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

          Kommentar


          • #6
            Viele Sachen die du nennst hat Redmine auch. Ich hatte mit dem Plugin geflunkert: https://jbox-web.github.io/redmine_git_hosting/ (Extra für gitolite + redmine)

            Die Blame Ansicht war mir völlig neu! Danke! Das ist der Hammer!
            Sehr hilfreich. Die Kommentarfunktion ist auch sinnvoll. Performance scheint auch gut zu sein, etwas worüber ich mit Gedanken gemacht hatte.
            Die SSH im Panel leicht zu hinterlegen ist ein Argument, das allerdings bei meiner Gruppengröße keine große Gewichtung bekommt. Hooks werden auch öfters genutzt.
            Habe jetzt einen zweiten Blick riskiert, ist Redmine dank der Spezialisierung, selbst mit den Plugins, in dem Gebiet unterlegen.
            Ich werde beides einsetzen.

            Hast mich überzeugt

            @ChristianK danke für den Einwurf, kannte ich auch noch nicht, obwohl Jira bekannt war.

            Kommentar


            • #7
              Update://

              Der Vollständigkeit halber, Redmine hat die 'annotate view', ist das gleiche wie die Blame view: http://www.redmine.org/projects/redm...cript/generate

              Es gibt folgende Unterschiede zwischen Redmine + Gitolite Plugin und Redmine + Gitlab (Für Gitlab):
              1. Hooks im Webpanel
              2. Feinjustierbarere Rechtsverwaltung & Teamverwaltung durch Webpanel,
              3 .Kommentare im Code, Code direkt via Webinterface editierbar (Gibt bei Redmine ein Plugin für Kommentare, allerdings Windows 98 Style: http://www.redmine.org/boards/3/topics/5878)
              4. Merges auch ohne Console via Webpanel anstoßbar, so dass Entwickler nur ihre Branch updaten und dann ohne einen Reviewer wählen (Nützlich für Leute die nur Leserechte auf Master haben sollen. Alternativer Workflow mit Redmine+Gitolab wäre nach dem pushen ein Support Ticket zu eröffnen mit der Bitte um Review+Merge. Zeitlich gesehen spart das die Zeit via Konsole auf den Server zu gehen und zu merken//die Updates zu pullen, morgen mit master und zu pushen)

              Werde jetzt Gitlab installieren.
              Danke.

              Eine letzte Frage:
              Wie würde der optimale Workflow bei Git aussehen, wenn ich eine Branch auf dem Remote habe (von einem anderen User gepusht) und diese mit der Master mergen möchte? (Er hatte dazu nicht die Berechtigung)

              a. Ich Fetch die Updates auf meinen lokal Klon, merge lokal, push --all
              b. Ich gehe direkt auf den Server per shh, merge dort.

              Rein aus Interesse, best Practice via Console.
              Denkbar wäre beides.

              Update://
              Jetzt erfolgreich installiert.
              Private Code Snippets hochladen als quasi Library ist auch ein super Feature!

              Kommentar

              Lädt...
              X