Jan W: Git - empfohlene Tutorials (mit Nachfragemöglichkeit) gesucht

Hallo!

Für einen konkreten Anwendungsfall würde ich mich gern mal in Git einarbeiten.

Da meine Zeit recht begrenzt ist, würde ich gern vorab klären/ nachfragen können, ob ich generell mit meiner Arbeitsweise Git nutzen kann.

Ich habe folgendes Setup/ folgende Voraussetzungen:

  • Auf einem Server, der unter Linux läuft, liegen meine Skripte.
  • Ich greife von einem Windows-PC per "WinScp" auf diese Skripte zu.
  • Zum Editieren startet "WinScp" beim Doppelklick auf eine Datei "Notepad++".
  • Es ist nicht sichergestellt, dass alle Programmierer, die die Skripte editieren, ein Versionskontrollsystem nutzen werden/ würden.

Weiß jemand, ob es möglich ist, da an irgendeiner Stelle das Versionskontrollsystem einzuklinken? Wenn das unter diesen Bedingungen nicht geht, welche Voraussetzungen müsste ich erfüllen, um Git sinnvoll nutzen zu können?

Kann jemand Tutorials aus eigener Erfahrung empfehlen, die ihr als lehrreich empfunden habt?

Vielen Dank Jan

  1. @@Jan W

    • Es ist nicht sichergestellt, dass alle Programmierer, die die Skripte editieren, ein Versionskontrollsystem nutzen werden/ würden.

    Dieses sollte aber sichergestellt werden. Zuallererst.

    Zweierlei sollte dabei helfen:

    • ein Tutorial (nach dem du ja hier fragst) – nicht nur für dich, sondern für alle Beteiligten.

    • ein git-Client mit GUI. Ich selbst hab auch keine Lust auf Kommandozeile und verwende SourceTree.

    LLAP 🖖

    --
    “I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl
  2. Kommt jetz drauf an was bei dir "Scripte" sind, optimalerweise entwickelt jeder in seiner eigenen Entwicklungsumgebung auf dem lokalen Rechner und synct dann nurnoch die Änderungen in ein gemeinsames Repo. Heisst aber z.B.: Apache, PHP, MySQL müssen dann auch auf jedem Rechner installiert sein (ggf. halt über Vagrant o.Ä.)

    1. @@chorn

      Kommt jetz drauf an was bei dir "Scripte" sind, optimalerweise entwickelt jeder in seiner eigenen Entwicklungsumgebung auf dem lokalen Rechner und synct dann nurnoch die Änderungen in ein gemeinsames Repo. Heisst aber z.B.: Apache, PHP, MySQL müssen dann auch auf jedem Rechner installiert sein (ggf. halt über Vagrant o.Ä.)

      Das ist oft so, aber nicht zwangläufig.

      Wie der Code gemeinsam gepflegt wird und wie der Code ausgeführt wird, ist ein getrenntes Paar Schuhe.

      Hier geht es um ersteres.

      LLAP 🖖

      --
      “I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl
    2. Kommt jetz drauf an was bei dir "Scripte" sind, optimalerweise

      Skripte: in erster Linie PHP/ Perl. In seltenen Fällen editiere ich auch HTML-Dateien.

      entwickelt jeder in seiner eigenen Entwicklungsumgebung auf dem lokalen Rechner und synct dann

      Ja, jeder entwickelt in einer anderen Umgebung.

      So müsste also das Versionskontrollsystem zwischen dem Linux-Server und dem Editor, den der jeweilige Programmierer nutzt, eingeklinkt sein?!

      1. Hallo

        Kommt jetz drauf an was bei dir "Scripte" sind, optimalerweise Skripte: in erster Linie PHP/ Perl. In seltenen Fällen editiere ich auch HTML-Dateien.

        entwickelt jeder in seiner eigenen Entwicklungsumgebung auf dem lokalen Rechner und synct dann Ja, jeder entwickelt in einer anderen Umgebung.

        So müsste also das Versionskontrollsystem zwischen dem Linux-Server und dem Editor, den der jeweilige Programmierer nutzt, eingeklinkt sein?!

        Nein. Git wird lokal betrieben. Es gehört zur Gruppe der Distribuited Version Control Systems (verteilte Versionskontrollsysteme). Jeder Mitarbeiter [1] hat seine lokale Kopie des Projekts, die ein eigenes Git-Repository ist, und pflegt seine Änderungen in dieses lokale Repo ein [2]. Da die Änderungen natürlich miteinander ausgetauscht werden sollen (sollen sie doch?), ist es sinnvoll, auf einem Webserver so etwas wie Gitlab oder Gitweb zu betreiben. Das sind Systeme, die Git-Repositories verwalten und diverse (mehr oder minder ausgefeilte) Funktionen, auch für die Zusammenarbeit, zur Verfügung stellen. @Christian Kruse hatte da auch noch eine Softwareempfehlung, die ich aber gerade nicht wiederfinde.

        Tschö, Auge

        --
        Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
        Wolfgang Schneidewind *prust*

        1. „Mitarbeiter“ im Sinne von an einem Projekt Mitarbeitender, Beteiligter. ↩︎

        2. Das heißt aber auch, dass man als Einzelkämpfer, ohne einen Server zu betreiben zu müssen, eine Versionsverwaltung nutzen kann. ↩︎

        1. Hallo Auge,

          […] ist es sinnvoll, auf einem Webserver so etwas wie Gitlab oder Gitweb zu betreiben. Das sind Systeme, die Git-Repositories verwalten und diverse (mehr oder minder ausgefeilte) Funktionen, auch für die Zusammenarbeit, zur Verfügung stellen. @Christian Kruse hatte da auch noch eine Softwareempfehlung, die ich aber gerade nicht wiederfinde.

          äh - hatte ich? Meinst du vielleicht Gogs?

          LG,
          CK

          1. Hallo

            […] ist es sinnvoll, auf einem Webserver so etwas wie Gitlab oder Gitweb zu betreiben. Das sind Systeme, die Git-Repositories verwalten und diverse (mehr oder minder ausgefeilte) Funktionen, auch für die Zusammenarbeit, zur Verfügung stellen. @Christian Kruse hatte da auch noch eine Softwareempfehlung, die ich aber gerade nicht wiederfinde.

            äh - hatte ich? Meinst du vielleicht Gogs?

            Ja und ja. :-)

            Tschö, Auge

            --
            Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
            Wolfgang Schneidewind *prust*
    3. Hallo

      Kommt jetz drauf an was bei dir "Scripte" sind, optimalerweise entwickelt jeder in seiner eigenen Entwicklungsumgebung auf dem lokalen Rechner und synct dann nurnoch die Änderungen in ein gemeinsames Repo.

      Jein. Jeder entwickelt auf dem eigenen Rechner, aber jeder hat dort, auf seinem Rechner, sein lokales Repository. Es kann aber zusätzlich ein gemeinsames Repository auf einem Server geben, dass allen als Austauschspeicher und Master dient (auch, wenn es, technisch gesehen, kein Master ist).

      Heisst aber z.B.: Apache, PHP, MySQL müssen dann auch auf jedem Rechner installiert sein (ggf. halt über Vagrant o.Ä.)

      Wenn, dann muss das – unabhängig von Git – zum testen des Codes installiert sein. Für Git selbst muss kein Webserver, kein PHP, kein MySQL installiert werden. Höchstens die Software für den gemeinsamen Server für Austausch und das Masterrepository erfordert die Installation dieser Komponenten.

      Tschö, Auge

      --
      Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
      Wolfgang Schneidewind *prust*
  3. Kann jemand Tutorials aus eigener Erfahrung empfehlen, die ihr als lehrreich empfunden habt?

    Die Tutorials von Atlassian sind hervorragend: https://www.atlassian.com/git/tutorials

    1. Hallo 1unitedpower,

      Die Tutorials von Atlassian sind hervorragend: https://www.atlassian.com/git/tutorials

      Mag das mal jemand ins Deutsche übertragen?

      Except where otherwise noted, all content is licensed under a Creative Commons Attribution 2.5 Australia License.

      Bis demnächst
      Matthias

      --
      Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
    2. Erst mal allen vielen Dank für die Unterstützung.

      Das mit der Versionskontrolle scheint mir jetzt nichts zu sein, was man so "nebenbei" mal installiert und nutzt :)

      Ein tolles Wochenende euch allen!

      1. Hallo

        Das mit der Versionskontrolle scheint mir jetzt nichts zu sein, was man so "nebenbei" mal installiert und nutzt :)

        Öhhm, doch und nö. Die Installation ist, zumindest bei Git, recht einfach. Allerdings bedarf die sinnvolle Nutzung, gerade, wenn diese gemeinsam erfolgt, einiger Überlegungen, Einarbeitungszeit und Absprachen.

        • Wie kleinteilig oder eben nicht kleinteilig sollen die dokumentierten Codeänderungen sein, die commitet werden?
        • Wie haben Commit-Nachrichten auszusehen?
          • Erfolgen sie als einzeilige Notiz?
          • Enthalten sie eine Beschreibung der Intention der Änderung?
          • Gibt es Vorgaben für Stil und Duktus der Notizen?
        • Wie sollen die Änderungen lokal behandelt werden?
          • Soll für jeden Bugfix, jedes Feature ein jeweils eigener Branch angelegt werden?
          • Werden in einem Branch verschiedene Dinge abgehandelt?
        • Wie erfolgt die Übernahme in den gemeinsamen Master (so vorhanden)?
          • Erfolgt ein Code Review vor der Übernahme?
          • werden alle Commits eines Features mit dem Merge übernommen oder werden sie zu einem Commit zusammengefasst?

        Es gibt also (unter anderem dazu) Gesprächsbedarf. Das behaupte ich jetzt einfach mal und bin mir ziemlich sicher, damit richtig zu liegen. Dennoch halte ich die Verwendung eines Versionierungswerkzeugs für empfehlenswert. Auch, wenn das Projekt recht übersichtlich wirkt. Auch und gerade, wenn es mehrere Beteiligte gibt.

        Tschö, Auge

        --
        Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
        Wolfgang Schneidewind *prust*
      2. Tach!

        Das mit der Versionskontrolle scheint mir jetzt nichts zu sein, was man so "nebenbei" mal installiert und nutzt :)

        Am besten mit einem Test-Repository probieren. Git hat zwar eine Menge Möglichkeiten, aber für den Anfang braucht man für das Tagesgeschäft nur eine Handvoll Aktionen. Es sei denn, ihr wollt gleich mit dem vollen Programm (sprich: Branchen) anfangen.

        dedlfix.

      3. Prinzipiell finde ich das mit Git sinnvoll. Aber das Prinzip bzw. die Art und Weise, wie das funktioniert, muss ich mir dann doch erst mal aneignen. Jetzt gar nicht so sehr die Befehle, sondern die grundlegende Struktur. Da gehe ich wohl von falschen Vorstellungen aus.

        Ich dachte bisher sieht das Setup so aus: |mein PC| -> |Git-Server| -> |Produktivserver|

        Also dass ich (und alle anderen Projektmitarbeiter) quasi direkt auf den gespiegelten Dateien auf dem Git-Server arbeiten (Kollaboration wie bspw bei GoogleDocs) und man dann mit einem Befehl alles auf den Produktivserver schiebt.

        So wie ich es jetzt hier aus euren Erläuterungen rauslese, hat jeder alle Dateien auf seinem PC, bearbeitet diese und schiebt die dann auf dem Git-Server. Und der schiebt diese dann auf dem Produktivserver.

        Na Weihnachten wird Zeit sein, sich mal Tutorials durchzulesen :)