Git ohne GitHub im lokalen Netzwerk nutzen

[rephluX]

Hallo Forum!

im Moment arbeite ich ohne Versionskontrolle. Das ist schlecht und soll geändert werden! Jetzt hab ich noch ein paar Verständnisfragen zu Git:

1) Wenn ich am Projekt arbeite, arbeite ich komplett lokal, was dann auch einen lokalen Webserver samt DB vorrausetzt (evtl VM)? Und das für jeden Entwickler?

2) Das Repository liegt dann auch lokal auf meinem Rechner? Selbst nach einem commit/push?

3) Wenn jetzt mehrere Entwickler Zugriff auf das Projekt bekommen sollen, ich aber kein (!) GitHub verweden will/kann, wie stell ich das am besten an? Kann ich auf einem lokalen Server im Netzwerk ein "Master"-Repository anlegen (im Prinzip wie bei SVN), und da sind auch alle Dateien, Versionen, Historie und Branches aller Entwickler vorhanden? Natürlich nur dann, wenn diese ihre Änderungen auch an den Server übertragen haben.

Danke für Antworten

 

[thes33k]

1) Git hat eine weitere Ebene bei Versionierung im Vergleich zu Klassikern wie svn/cvs. Du commitest lokal, sodass du lokal eine Versionshistorie hast, in der du jederzeit vor und zurueck gehen kannst. Wenn alles funktioniert, pusht du spaeter dann deine commits als bundle in das remote-repo. Du willst nicht pro Entwickler ein remote-repo haben. Es reicht also ein Server, der das remote-repo haelt.

2) Commits sind immer lokal, push kann sowohl in lokale branches als auch ins remote-repo sein.

3) Es gibt alternativen zu github. Z.b. gitlab (http://gitlab.org/). Das lohnt sich immer dann, wenn du eine graphische Darstellung deiner Repos und mehr als nur ein Repo verwalten moechtest. Hast du quasi nur ein Produkt und weisst, wie man repos per cli steuert, lohnt sich sowas nicht und ein einfacher git daemon tuts auch.

 

[Freezedevil]

Ich würde das Repository an eine für alle erreichbare Stelle im Netzwerk legen. Von diesem Verzeichnis aus kann gepullt werden, sodass die Dateien dann bei jedem zum Bearbeiten und Commiten lokal liegen. Beim Push werden sie wieder in das Verzeichnis geschrieben. Das arbeitet sich dann im Prinzip genauso wie mit Github.

FYI falls Github nur ausscheidet weil man kostenlos keine privaten Repos anlegen kann, kann ich dir Bitbucket empfehlen.

 

[NullPointer]

Die "für alle erreichbare Stelle" kann übrigens auch eine Dropbox o.ä. sein

 

[Freezedevil]

Jup, falls es doch mal Online verfügbar sein muss bietet sich die Dropbox an. Dann würde ich allerdings lieber zu einem Codehoster wechseln.

Hier noch ein Link zum anlegen eines lokalen Repos http://tiredblogger.wordpress.com/2009/11/09/creating-local-git-repositories-yeah-its-that-simple/

 

[rephluX]

Danke euch soweit! Gitlab sieht schonmal gut aus. Da es auf jedenfall mehrere Projekte sind, bietet sich so eine Oberfläche schon an

Die zusätzliche Ebene in Git ist mir bereits bekannt. Genau deswegen will ich ja auch gerne Git einsetzen anstelle von svn ;-) Was ich allerdings noch nicht ganz verstanden hab, ist die Reihenfolge, wie ich welche Repos anlege. Ist das egal? Also ob erst das lokale oder erst das remote Repo? Und vor allem, woher weiß das lokale Repository, wo mein Remote Repository liegt?

Github scheidet deswegen aus, weil wir keinen Open-Source-Code schreiben und daher die ganzen Quelltexte ungern auf "öffentlichen" Server liegen haben wollen. Daher sollen die Remote-Repos auch nur im internen Netz abgelegt werden.

 

[Backslash]

Erstmal sind alle git repositories gleichwertig, für Dokumentation zu remote Servern schau dir mal das an: http://git-scm.com/book/en/Git-Branching-Remote-Branches

Ich selbst verwende Gitolite zur Verwaltung der Repositories auf dem zentralen Server und GitWeb als Weboberfläche.

 

[Troublegum]

Was ich allerdings noch nicht ganz verstanden hab, ist die Reihenfolge, wie ich welche Repos anlege. Ist das egal? Also ob erst das lokale oder erst das remote Repo? Und vor allem, woher weiß das lokale Repository, wo mein Remote Repository liegt?

Oft läuft es so, dass du auf deinem zentralen Server ein Repository anlegst
und das dann auf deinen lokalen Rechner klonst. So weiß dein lokales Repository, dass es eine "upstream"-Quelle gibt, woher das Repository geklont wurde.


Gitweb ist wenig ansprechend und Gitlab ist ein echt toller Github-Klon. Dafür brauchst du aber natürlich einen eigenen Server und die Installation ist nicht ganz trivial. Wenn du gleich losstarten willst, kann ich dir www.bitbucket.org empfehlen. Dort bekommst du unbegrenzt viele private Repositories, die du (in der kostenlosen Variante) mit bis zu 5 Mann bearbeiten kannst.

 

[Backslash]

Der Vorteil von gitweb ist, dass es wirklich schnell und einfach einzurichten ist - und die volle Funktionalität von gitlab/github wird nicht immer benötigt. Aber wenn man die Funktionen braucht ist gitlab natürlich eine gute Sache.

Das Design von gitweb lässt sich übrigens recht leicht anpassen, z.B. mit http://kogakure.github.io/gitweb-theme/ und auch Syntax Highlighting ist einfach einzurichten.

 

[rephluX]

Ich hab mal zum testen ein wenig rumgespielt, aber irgendwie scheint es nicht so zu laufen, wie ich es gerne will. Zum testen hab ich gerade leider nur zwei Windows-Maschinen da. Als Client benutz ich einen Windows 7 PC und als "Server" eine Windows-XP VM. OpenSSH ist bereits auf der XP VM installiert. Mit Putty komm ich drauf (Passworteingabe, Passphrase will nicht so richtig).

Auf dem Server ist ein Repo vorhanden (erstellt von einem normalen Repo mit der --bare Option). Wenn ich jetzt auf dem Client in der Gitbash ein

git clone user@gitserver:/projects/test-project.git

eingebe, dann werde ich aufgefordert, das Passwort für den SSH-Benutzer einzugeben. Hab ich dies getan, bekomm ich in der Gitbash aber anschließend folgenden Fehler angezeigt:

git-upload-pack: not found
fatal: Could not read from remote repository

Please make sure you have the correct access rights and the repository exists.

Ist das ein SSH-Fehler? Oder ein Fehler in Git? Der SSH-Zugriff funktioniert ja sowohl mit Putty als auch direkt aus der Gitbash heraus. Nach etwas Google-Recherche scheint das wohl ein Pfadproblem zu sein, weswegen Git hier den Dienst verweigert.

Per Fileystem liegt das Git-Repo im Netz unter der folgenden Adresse:

\\gitserver\projects\test-project.git

(gitserver ist die Windows XP VM)

Jetzt aber die große Preisfrage: Was muss ich noch einstellen? Und vor allem: WO muss ich das einstellen? Auf dem Client? Auf dem Server? Schön wäre natürlich auch, dass ich nicht jedesmall immer das SSH-Passwort eingeben muss. Aber das ist erstmal nicht so wichtig ;-)

Danke für Hilfe

 

[Backslash]

Wenn du eine VM hast, wieso installierst du da nicht einfach Linux?

 

[rephluX]

Wenn du eine VM hast, wieso installierst du da nicht einfach Linux?

Ich hab eine mit Windows, um einfach nur mal kurz testweise Git zu probieren. Warum soll ich mir dann die Arbeit machen und noch erst Linux zu installieren?

 

[NemesisFS]

Hast du denn die benötigten Rechte, um auf das Directory zuzugreifen?

Die Passwort Eingabe lässt sich durch public-private keys umgehen, das ist generell sinnvoll weil sicherer. Bei Putty kann man die dann auswählen, sie müssen halt beim Server hinterlegt werden. Mit Windows kenne ich mich da nicht so aus, unter Linux wäre die passende Datei für den public-key /home/user/.ssh/authorized_keys.

 

[Backslash]

Ganz einfach weil das alles unter Linux in ein paar Minuten problemlos funktioniert - und weil die meisten damit mehr Erfahrung haben und dir helfen können.

 

[ARNOFPS]

Das kann ich nur unterstreichen. Git funktioniert nun mal per SSH, das ganze auf Windows aufzusetzen wäre doch viel zu kompliziert, dann lieber die Linux Variante in einer VM.

Ich hab damals mit Gitosis angefangen, bin anschließend zu Gitolite gewechselt und schlußendlich bei Gitlab gelandet. Gitlab ist sowas, wie Github, nur eben offline. Ich verwalte damit mittlerweile 74 Projekte in 24 Gruppen.

Als Windows Client eignet sich Sourcetree sehr gut.

 

[rephluX]

Ich bestreite ja gar nicht, dass es unter Linux besser läuft Nur muss ich ja die VM am Ende auch hier in das Firmennetz einbinden, und DAS wird eher nicht so schnell passieren. Da wir allerdings eine Windows Server VM haben, bietet sich da (leider) Windows erstmal an.

Die Fehlermeldung ist allerdings jetzt auch verschwunden. Das lag, wie ich vermutet hatte, an einem falschen oder fehlenden Pfadangabe zu den Git-Binaries. Also einfach noch schnell in die Path-Umgebungsvariable den Pfad eingetragen (z.B. C:\Program Files (x86)\Git\libexec), kurz neustarten, und die Fehlermeldung ist verschwunden.

Dafür ist der clone-Befehl dann immer noch nicht erfolgreich. Nachdem ich das Passwort für den ssh-Benutzer eingegeben hab passiert genau nichts. Es wird zwar lokal der Ordner für das Repo angelegt, darin befindet sich auch ein .git Ordner. Aber die eigentlichen Dateien und Ordner aus dem Repo sind nicht drin. In der Git-Bash erscheint dann auch keine Ausgabe oder sonstige Fehlermeldung.

Aber da ich ja anscheinend der einzige bin, der Git auf einem Windows-System betreiben will, steh ich wohl mit dem Problem alleine da

 

[ARNOFPS]

Ich finde, dass Versionsverwaltung doch ne sehr kritische Anwendung ist. Zwar hat man immer eine Kopie des Repo's auf dem eigenen Rechner, trotzdem sollte man das ganze vernünftig angehen, gerade in einem Firmennetz, da dies ja mehr oder weniger das Kapital des Unternehmens ist.

Ich mein, was machst Du, wenn das Repo aus irgendwelchen Gründen zerschossen wird und keiner mehr drauf zugreifen kann?

Wie schon bereits erwähnt, nutze ich ja Gitlab, übrigens auch in der Firma und auch in einer VM. Die Gründe für eine VM sind Backups und Hardwareunabhänigkeit. Wenn uns hier der Server auf dem die VM läuft mal abrauchen sollte, wird einfach ein neuer mit dem letzten Snapshopt der VM gestartet, keine Ausfallzeiten und kein Datenverlust.

Aber ich höre jetzt auf dir die Windows-Bastel-Kiste auszureden

 

[rephluX]

Als Windows Client eignet sich Sourcetree sehr gut.

Frag mich nich wieso, aber damit gehts einwandfrei! URL zum Remote-Repo angegeben (\\local.server\projects\project.git) und et voila: Das Projekt wird problemlos auf den lokalen Rechner geklont und steht zum Arbeiten bereit. Direkt mal ein paar Commits gemacht und anschließend einen Push auf das Remote Repo. Die Software ist wirklich super, vor allem für mehrere Branches ist die wirklich praktisch.

Ich finde, dass Versionsverwaltung doch ne sehr kritische Anwendung ist. Zwar hat man immer eine Kopie des Repo's auf dem eigenen Rechner, trotzdem sollte man das ganze vernünftig angehen, gerade in einem Firmennetz, da dies ja mehr oder weniger das Kapital des Unternehmens ist.

Ich mein, was machst Du, wenn das Repo aus irgendwelchen Gründen zerschossen wird und keiner mehr drauf zugreifen kann?

Wie schon bereits erwähnt, nutze ich ja Gitlab, übrigens auch in der Firma und auch in einer VM. Die Gründe für eine VM sind Backups und Hardwareunabhänigkeit. Wenn uns hier der Server auf dem die VM läuft mal abrauchen sollte, wird einfach ein neuer mit dem letzten Snapshopt der VM gestartet, keine Ausfallzeiten und kein Datenverlust.

Aber ich höre jetzt auf dir die Windows-Bastel-Kiste auszureden

Nein, Du hat mit allem was Du schreibst recht! Und genau DAS ist ja auch der Grund, weswegen ich die Remote-Repos (erstmal) auf unsere Windows VM legen möchte. Eben WEIL die VM komplett im Backup-Prozess drin ist. Um sowas vergleichbares mit einer Linux VM aufzusetzen, dauerts dann leider erstmal eine Weile. Und bezahlt werden muss das ja dann auch noch

Aber dennoch eine Verständnisfrage: Git selbst ist es doch egal, WO die Dateien liegen? Ich mein, die"Windows-Bastel-Kiste" kann doch Git egal sein, wenn es denn dann einmal richtig aufgesetzt ist und funktioniert, oder?

 

[ARNOFPS]

Frag mich nich wieso, aber damit gehts einwandfrei! URL zum Remote-Repo angegeben (\\local.server\projects\project.git) und et voila: Das Projekt wird problemlos auf den lokalen Rechner geklont und steht zum Arbeiten bereit. Direkt mal ein paar Commits gemacht und anschließend einen Push auf das Remote Repo. Die Software ist wirklich super, vor allem für mehrere Branches ist die wirklich praktisch.

Ich tippe mal stark darauf, dass das Programm direkt aus dem Remote Git Repo klont, ohne jetzt einen Umweg über SSH usw zu machen.

Aber dennoch eine Verständnisfrage: Git selbst ist es doch egal, WO die Dateien liegen? Ich mein, die"Windows-Bastel-Kiste" kann doch Git egal sein, wenn es denn dann einmal richtig aufgesetzt ist und funktioniert, oder?

Korrekt. Solange Du in das Remote-Repo pushen kannst, ists egal wo die Daten liegen.

Einen wirklichen Nachteil gibts sonst nicht, ausser dass die Rechteverwaltung über Windows gemacht werden muss .

 

[rephluX]

Einen wirklichen Nachteil gibts sonst nicht, ausser dass die Rechteverwaltung über Windows gemacht werden muss .

Da ich jetzt zum lokalen arbeiten trotzdem eine Linux VM brauchte, hab ich mir eine Ubuntu VM installiert, in der ein LAMP System läuft. Das entsprechende Verzeichnis in Windows als Netzlaufwerk eingebunden, so dass ich weiter von meiner Windows Arbeitsumgebung arbeiten kann. Das Master-Repo wird dann allerdings weiterhin auf einem Windows System liegen, wohin dann alle Entwickler ihre commits pushen. Bedeuet: Mein lokales Repo liegt in der Linux VM, auf das ich mit meinem Windows Client per PHP IDE drauf zugreife und Dateien bearbeite. Über SourceTree mach ich dann vom Windows Client einen commit in das lokale Repo in der VM. Und anschließend dann bei Bedarf einen push ins Remote Repo. Soweit so gut, alles läuft

Nur wie soll ich jetzt Git richtig einstellen (auf beiden Systemen), dass die Dateien im Bezug auf Zeilenümbrüchen und/oder Whitespaces richtig auf den jeweiligen Systemen richtig verarbeitet werden? Ich hatte bis eben das Phänomen, dass mir ein "git status" in der Git Bash auf den jeweiligen Betriebssystemen unterschiedliche Anzeigen gebracht haben: "Nothing to commit" auf Windows vs. "modified" oder "typechanges" auf Linux. Obwohl natürlich keine Änderungen vorgenommen wurden. Ein commit brachte dann auf dem anderen Betriebsystem das gegenteilige Ergebnis.

Nach einer kleinen Recherche bin ich dann auf diesen Eintrag in der Git Help gestoßen. Die Lösung mit der .gitattributes Datei find ich schomal sehr gut, weil die Einstellungen dann immer im Projekt vorhanden sind und nicht immer wieder auf jedem Client neu eingestellt werden müssen. Ist das jetzt wirklich DIE ideale Lösung, um das Problem der verschiedenen Betriebssystemen in den Griff zu bekommen? Bevor ich die .gitattributes angelegt hatte, hatte ich die verschiedensten Lösungsansätze probiert, die alle irgendwelche Einstellungen in der gitconfig vorgenommen aber nicht wirklich funktioniert haben.

Meine .gitattributes sieht jetzt wie folgt aus:

# Set default behaviour, in case users don't have core.autocrlf set.
* text=auto

# Explicitly declare text files we want to always be normalized and converted 
# to native line endings on checkout.
*.php text
*.js text
*.css text
*.scss text
*.json text
*.yml text

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary
*.gif binary
*.phar binary

Ich dachte eigentlich, es wäre mit Linux einfacher!?