TortoiseGIT und Repository auf zentralem Server



  • Danke schonmal für die Antwort. Aber TortoiseGit sind Shell-Extensions für Windows. Daher wollte ich eigentlich nicht so gerne mit Kommandozeilen-Geschichten arbeiten, obwohl das wohl auch irgendwie möglich ist.
    Mittlerweile hab ich es zumindest hinbekommen, über Netzlaufwerke die Repositorys zu clonen und pushen/pullen. Da ich das allerdings nur intern machen kann, ist das noch nicht der Weisheit letzter Schluss. Über SSH-Verbindungen hab ich das noch nicht hinbekommen.... 😕



  • Die oben genannten Befehle brauchst Du ja nur fuer das anfaengliche Setup.

    Danach sollte TortoiseGit einfach so (TM) funktionieren, ich habe gerade ein Projekt mit zwei Windows-Committern mit Tortoise-Git abgeschlossen, da gab es keinerlei Probleme.



  • Ich bin mittlerweile tatsächlich schon etwas weiter gekommen... nun hapert es aber noch an der ssh-Verbindung beim push/pull. Key-file etc. ist erstellt und eingerichtet. Per putty kann ich mich auch problemlos mit diesem key auf dem Server einloggen.
    Versuche ich allerdings nun mein Repo auf den Server zu pushen, (URL sieht so aus: "ssh:\<USER>@<SERVER>\home\users\<USER>\Git_test") dann fragen sowohl TortoisePlink als auch OpenSSH (habe den SSH-Client testweise mal gewechselt) nach dem Passwort. Und das immer wieder und wieder und wieder und wieder.... woran zum Henker kann das liegen?? 😕 Das Password, das ich eingebe ist exakt das gleiche wie das, was ich zum einloggen mit dem key-file über Putty verwende...



  • Doch hoffentlich nicht wirklich mit Backslashes, oder?

    Lass am besten mal Pageant laufen, TortoiseGit kann man irgendwo mitteilen, dass es den verwenden soll (und somit den SSH-Key statt Password-Auth).



  • Offtopic:
    Ich nutze zur Versionsverwaltung Subversion, will aber aufgrund der Performance und der Umständlichkeit der Bedienung auf ein anderer VC System wechseln.
    Git klingt sehr cool, gerade weil es TortoiseGit dafür gibt.
    Wie schaut das aus - ich möchte meinen Code auf einem zentralem Server halten, von dem sich mehrere Entwickler Code auschecken. Es soll also alles zentralisiert laufen, ich lege keinen Wert auf die dezentrale Struktur.
    Würde hier die Benutzung von GIT Sinn machen? Gibt es Erfahrungen mit SVN vs. GIT?



  • Headhunter schrieb:

    Git klingt sehr cool, gerade weil es TortoiseGit dafür gibt.
    Wie schaut das aus - ich möchte meinen Code auf einem zentralem Server halten, von dem sich mehrere Entwickler Code auschecken. Es soll also alles zentralisiert laufen, ich lege keinen Wert auf die dezentrale Struktur.
    Würde hier die Benutzung von GIT Sinn machen? Gibt es Erfahrungen mit SVN vs. GIT?

    Klar.

    Kurz zusammengefasst: Wir haben 2010, Subversion ist tot, nimm Git. 🙂

    Längere Version:
    Ein derart zentralisiertes Setup lässt sich mit Git wunderbar umsetzen, Du hast aber unter anderem folgende Vorteile:

    • Gesamtes Repo Offline verfügbar, kein Server für Diffs, Commits oä. benötigt.
    • Sehr bequemes Branching.
    • Weil Commits und Pushes getrennt sind, brauchst Du auch wenn Du Branches nicht verstanden hast, keine Angst haben, aktuelle Versionen kaputtzumachen, wenn Du committest; committen und pushen sind zwei paar verschiedene Schuhe, Versionierung und Veröffentlichung sind somit sauber voneinander entkoppelt.
    • Sauschnell.
    • Winzige Repos.
    • Staging-Area.
    • git rebase (Du kannst bspw. siebzehn Commits in einer Branch zu zwei sauberen, hübschen zusammendampfen, bevor Du sie pusht.)
    • Wenn Dir der zentrale Server eingeht, hast Du auf alle Fälle noch n Backups des gesamten Repos, wobei n==Anzahl der Entwickler, die das Repo ausgecheckt hatten.

    Eine nette Zusammenfassung gibt es zB. hier: http://whygitisbetterthanx.com/

    Ein paar Workflow-Möglichkeiten und eine sonst auch recht witzige Präsentation, die mir gut gefallen hat, gibt es hier: http://www.slideshare.net/err/git-machine

    Potentiell negatives, was ich nicht verschweigen möchte:

    • Richtig produktiv ist man mit Git IMO erst dann, wenn man einigermaßen versteht, wie es funktioniert. Würde daher stark empfehlen, dass Du Dir irgendein Buch darüber zulegst, zB eines der beiden hier (ersteres gibts auch online):
      Pro Git | ISBN: 1430218339 Version Control with Git | ISBN: 0596520123
    • Die Submodule-Unterstützung von Git ist (noch) nicht besonders gut. Tut mir persönlich eigentlich nie weh, zumal die oben genannten Bücher auch darauf eingehen, was es für Möglichkeiten und Alternativen bzw. Workarounds gibt, sollte der Vollständigkeit halber aber dazugesagt werden.

    Achtung, Stolpersteine beim Setup eines zentralen Repos:

    • Wenn alle in ein Repo pushen, musst Du Dich ein bisschen mit Sticky-Bit und möglicherweise ACL spielen, damit nicht irgendwer Dateien oder Verzeichnisse anlegt, die für andere nicht überschreibbar sind.
    • Das zentrale Repo sollte ein Bare-Repo sein.

    Ich würde mittlerweile eher nicht mehr mit einem einzigen zentralen Repo arbeiten. Nicht, weil das mit Git nicht super geht, sondern einfach, weil n Repos pro User auf einem zentralen Server so toll funktionieren. 🙂 (Aber schau Dir einfach die Präsentation da oben an, da werden einige Workflows recht gut erklärt.)



  • Danke für die tolle Erklärung nman. Die Beschreibungen von Git sehen wirklich sehr vielversprechend aus, ich werde das mal ausprobieren.
    So ganz bin ich von dem verteilten System aber noch nicht überzeugt. In meinem Usecase gibt es einen zentralen SVN-Server und ein Produktiv+Stagingsystem. Diese Server werden zentralisiert gesichert. Dann gibt es 2-3 Entwickler, die an verschiedenen Projekten arbeiten.
    Vorteil SVN: Bekannter Workflow, stupide bis einfache Logik (Branching kann man eh vergessen in SVN). Git macht es da evtl. etwas komplizierter - muss ich aber mal ausprobieren 🙂



  • Headhunter schrieb:

    Danke für die tolle Erklärung nman. Die Beschreibungen von Git sehen wirklich sehr vielversprechend aus, ich werde das mal ausprobieren.
    So ganz bin ich von dem verteilten System aber noch nicht überzeugt. In meinem Usecase gibt es einen zentralen SVN-Server und ein Produktiv+Stagingsystem. Diese Server werden zentralisiert gesichert. Dann gibt es 2-3 Entwickler, die an verschiedenen Projekten arbeiten.
    Vorteil SVN: Bekannter Workflow, stupide bis einfache Logik (Branching kann man eh vergessen in SVN). Git macht es da evtl. etwas komplizierter - muss ich aber mal ausprobieren 🙂

    Nö, git macht es genauso.
    Du hast eben einen Git-Server und ein Produktiv+Stagingsystem (kann z.B. ein Klone [git clone] sein). Der Workflow kann z.B. dann sein:

    Projekt A auf Server mit master branch. Master branch ist der Staging-Branch.
    Jeder Entwickler klont das Projekt mit git clone
    Jeder Entwickler macht ein branch, mit git checkout -b entwickler-name
    In entwickler-name branch kann jeder Entwickeln,
    Um alles auf den Server zu pushen:

    git checkout master
    git pull origin master  # hole die letzten Änderungen vom Server
    git merge entwickler-name # merge lokale Änderungen
    git push origin master # push auf Server
    

    Das ist das gleiche wie in SVN, du kannst Git genauso wie SVN verwenden, nur mit allen Vorteilen von Git.



  • Ich hänge mich hier mal rein.

    Ich habe mir soeben auf meinem VServer (Ubuntu 8.04) git installiert.
    Danach habe ich einen neuen User git angelegt und unter /home/git/repo/ ein neues repo installiert.

    versuche ich nun

    git clonse ssh://git@meinServer.de/repo/

    kann ich mich nicht connecten.

    Der SSH Zugriff auf den Server via Putty funktioniert allerdings für gewöhnlich
    Jemand ne Idee



  • Hab das Problem gelöst. Danke 🙂



  • Was war die Lösung?

    Zugriffsrechte?

    Oder sowas?
    git clone ssh://git@meinServer.de/repo/.git



  • nman schrieb:

    Was war die Lösung?

    Zugriffsrechte?

    Oder sowas?
    git clone ssh://git@meinServer.de/repo/.git

    git hatte putty als ssh client eingestellt. Nachdem ich es auf openssh umgestellt habe alles bestens.



  • Also ich bekomme Git nicht auf meinem Server, habe kein SSH, kann nur mit FTP verbinden und Daten so hin und her schieben 😞

    Benutze auch TortoiseGit da ich aus der SNV Ecke mit TortoiseSvn komme.
    Ich bin von SVN hauptsächlich zu GIT gewechselt da das Backup eines Repos einfacher ist.
    Aber um GIT vs. SVN ist hier nicht das Thema, dafür gibt es http://www.c-plusplus.net/forum/viewtopic-var-t-is-259899-and-highlight-is-.html


Anmelden zum Antworten