[Q] Lokaler Git-Server

Hi Robert,

ich kann dir "gitosis" empfehlen, das verwende ich selbst und es ist 
sehr einfach, eine SSH-only-Lösung (ok, ist in Python geschrieben) und 
man braucht auf dem Server nur einen Benutzer anzulegen und jeder, der 
Zugriff haben soll, muss sich einen SSH-Schlüssel machen und den legt 
man dann in ein Verzeichnis auf dem Server (dazu gibt es selbst wieder 
ein Git-Repo, ist wirklich einfach).

Generell ist aber zu sagen, dass das ja alles "Krücken" sind da die 
distributed-Sache nicht nur Vorteile hat. Mit dieser Lösung aber gibt es 
auch einen Server, der immer erreichbar sein kann und auf den alle 
pushen können. Es gibt aber keinerlei technischen Unterschied zwischen 
dem Server und einem Remote-Repositorium eines anderen "echten" 
Menschen, es ist eine reine Vereinbarung, dieses besondere Repositorium 
zu "dem" Server zu machen. Die eigenen Aktivitäten push/pull auch mit 
anderen Benutzern sind damit nicht eingeschränkt, du kannst auch auf dem 
Server branches machen oder deinen experimental-Branch in den Master des 
Servers pushen, wie du willst.

Ach ja, Klonen etc. funktioniert dann z.B. so:

git clone git@DEIN_SERVER:mein_tolles_projekt.git

... vorher muss man in einer Konfig-Datei sagen, dass es 
mein_tolles_projekt gibt und welche Benutzer (== SSH-Schlüssel) dort 
Zugriff haben sollen.

Ach, ich verstehe jetzt erst deine Frage lgaub ich! Wenn du nur "git 
push" eingibt, ist das eine obsolete Syntax -- sollst du nicht machen! 
Du sollst eingeben

git push origin master

Was heisst, "pushe meinen atuellen Branch in den "master"-Branch des 
Ziels origin" und "origin" ist nunmal der Default-Name wenn man mit "git 
clone" ein Repositorium klont (oder auscheckt oder wie auch immer). Du 
kannst auch

git add remote robert robert@anderer_rechner

eintippen und dann entsprechend dorthin pushen mit

git push roberts master

Ich hoffe, das hilft jetzt weiter :)

Grüsse
Philipp

Jedes Git Repo kann mit jedem anderen (derselben Basis) pushen / pullen 
etc. solange das eine Repo zum anderen eine Verbindung hat (Internet, 
auf derselben Platte...).
Bei Git Hub ist das folgendermassen gelöst: jeder erhält seinen Klon 
(Fork) auf dem Server von Git Hub, somit ist jedes Repo jederzeit 
erreichbar. Schlussendlich arbeitest du aber auf einem lokalen Klon, 
deines schon geklonten (geforkten) Repos bei Git Hub.

Wenn du einen eigenen Server einrichtest und sich jemand das Repo auf 
seine Platte klont, muss dieser Jemand ja nicht unbedingt auch einen 
Server haben und somit kann niemand von aussen auf dieses Repo 
zugreiffen.

Du musst eben neben dem Klonen auch einen Fork-Dienst anbieten, der das 
Repo auf demselben Server Klont.

Philipp schrieb:
> ich kann dir "gitosis" empfehlen, das verwende ich selbst und es ist
> sehr einfach, eine SSH-only-Lösung (ok, ist in Python geschrieben) und
> man braucht auf dem Server nur einen Benutzer anzulegen und jeder, der
> Zugriff haben soll, muss sich einen SSH-Schlüssel machen und den legt
> man dann in ein Verzeichnis auf dem Server (dazu gibt es selbst wieder
> ein Git-Repo, ist wirklich einfach).

Funktioniert bereits. Auch andere User funktionieren schon :)

Peter schrieb:
> Wenn du einen eigenen Server einrichtest und sich jemand das Repo auf
> seine Platte klont, muss dieser Jemand ja nicht unbedingt auch einen
> Server haben und somit kann niemand von aussen auf dieses Repo
> zugreiffen.

Entweder er pusht immer seinen Klon auf das zentrale Repository, oder 
man stellt den "Fork"-Dienst zu Verfügung. Oder jeder der das Repository 
klont hat einen eigenen Server am laufen.

Peter schrieb:
> Du musst eben neben dem Klonen auch einen Fork-Dienst anbieten, der das
> Repo auf demselben Server Klont.

Ja das verstehe ich. So wie es mir scheint ist das mit gitosis nicht 
möglich.

Wenn ich das mit dem zentralen Repository lasse, kann jeder lokal 
branchen und mergen wie er will und pusht das auf den Server. Werden in 
diesem Fall alle Commits aller User die das Repo geklont und wíeder 
gepusht haben am Server sichtbar?

Maser
Experimental ----*--*---*---*--*------*-*-*----*-----
Stable           |\-------*----|---------------|----
Bugfixing        \--*--*--/          \--*-*-/

Am Server gibt es drei Branches: Experimental (master), Stable, 
Bugfixing. Auch lokal hat jeder User diese Branches. Zusätzlich hat 
jeder noch lokal seine eigenen Branches an denen er arbeitet. Die merged 
er in einen der drei offiziellen Branches.

Ist so am sinnvoll? Oder gibt es bessere Ansätze?

Gruß Robert

Will ich meinen "master" in den "experimental" des entfernten Repos 
pushen, dann muss ich folgendes machen:

git checkout master
git push origin experimental

oder in die andere Richtung:

git checkout master
git fetch origin
git merge origin/experimental

(fetch ... merge ist ja die "Langversion" von pull und "origin" eben 
weil es der voreingestellte Standard ist)

Es muss also nicht jeder Benutzer exakt die Branches haben, die beim 
Server vorhanden sind, es muss nur jeder wissen, was er wohin pushen 
will. Auch wenn ich z.B. in deinem Beispiel "bugfixing" habe, kann ich 
das beim Server in den Master pushen wenn ich will, also die 
Branchbezeichnung alleine ist noch keine Sicherheitsmaßnahme gegen 
versehentliches falsches pushen.

Ansonsten hat deine Version gegenüber dem Tagging-Mechanismus den 
Vorteil, dass man auch später noch Bugfixes in den Master machen kann, 
es also kein "Snapshot" ist sondern wirklich eine stabile (aktuelle) 
Version.

Robert schrieb:
> Wenn ich das mit dem zentralen Repository lasse, kann jeder lokal
> branchen und mergen wie er will und pusht das auf den Server. Werden in
> diesem Fall alle Commits aller User die das Repo geklont und wíeder
> gepusht haben am Server sichtbar?

IMHO nicht. Auf dem Server wird nicht die gesammte Geschichte 
gespeichert, sondern nur den Kommentar zum Mergen und die letzte Version 
des Users. Alle Änderungen der einzelnen User werden also unter dem 
Kommentar zum Merge zusammengefasst. Damit bleibt der Server schön 
aufgeräumt und jeder kann sich so zB. in Branches ausleben ohne die 
Branches auf dem Server zuzumüllen.

Sorry für den doppelpost, aber ich hab noch mehr zu sagen...

Robert schrieb:
> Am Server gibt es drei Branches: Experimental (master), Stable,
> Bugfixing. Auch lokal hat jeder User diese Branches. Zusätzlich hat
> jeder noch lokal seine eigenen Branches an denen er arbeitet. Die merged
> er in einen der drei offiziellen Branches.
>
> Ist so am sinnvoll? Oder gibt es bessere Ansätze?

Ja, das ist sinnvoll. Ein User kann natürlich auch nur ein Branch klonen 
und nur darauf arbeiten. Im Normalfall wird das wohl so sein. 
Grundsätzlich gilt, ein Branch wird nur angelegt, wenn er benötigt wird. 
Am Anfang wird man also oft nur den master haben. stable dann erst beim 
ersten release oder testreleas und bugfixing erst wenn man in der 
stable-Version bugs zum fixen hat.

gruss Peter