Fragen zu GIT

S

Struct

Gast
Hallo,

ich habe mit Hilfe der folgenden Anleitung Git auf meinem Webspace eingerichtet. Funktioniert soweit auch. Zur Verbindung nutze ich GIT + TortoiseGit. Hier noch die Anleitung:
http://www.dennislizarzaburu.de/blogs/1/git+und+all-inkl

Jetzt hätte ich aber noch ein paar Git spezifische Fragen. Habe sie zwar schon gegoogelt und ein paar Seiten darüber gelesen, aber ich habs nicht ganz kapiert.

Zunächst habe ich 2 Anwendungsfälle:
1. Ich möchte ein Git Repository, um meine eigene Bachelorarbeit zu versionieren
2. Ich möchte ein Git Repository, um Programmcode zu verwalten, an dem bis zu 4 Leute momentan arbeiten

Laut der Anleitung erstelle ich das Repository auf meinem Webspace über SSH (ich nehme Putty) mit dem Befehl:
Code:
mkdir repositoryName.git
git --bare init

Meine Fragen:
1. Ich begreife den Unterschied zwischen bare und non-bare Repository nicht. Es heißt bare sei für working, non-bare für sharing. In bare gibt es keine Verzeichnisstruktur. Was bedeutet das? Ich kann doch aber Order committen?

2. In den bisherigen Repositories haben wir immer Pullen können. Das geht ja nur bei non-bare. Ist das also das richtige Repositoryfür gemeinsames Arbeiten an einem Projekt (Programmcode)? Und was würdet ihr mir für meine Bachelorarbeit empfehlen?

3. Wie kann ich jetzt noch verschiedene Benutzer hinzufügen? Mit der Anleitung melden sich ja alle Benutzer über die gleichen SSH Zugangsdaten an. Im TortoiseGit unter Einstellungen kann man zwar Name und Email angeben, aber das ist ja nicht so eindeutig oder?

Erstmal vielen Dank. Wie gesagt, es gibt wirklich viele Seiten über das Thema. Aber ich habs einfach nicht 100% kapiert. Vielleicht könnt ihr mir ja dabei helfen.
 
Ein bare Repository ist nicht dafür geeignet, direkt darauf zu arbeiten. Es dient nur als "Zentrale". Alle, die damit arbeiten wollen, klonen es und bekommen dadurch ihr eigenes (non-bare) Repo. Darauf wird gearbeitet und die Änderungen mit "git push" in die Zentrale zurückgeschickt. Für euer gemeinsames Projekt würde ich das genau so aufsetzen.

Da du an deiner Bachelorarbeit alleine arbeiten willst, reicht dafür ein einziges Repo; das müsste dementsprechend non-bare sein. (Tip: Legst du das Repo in einen Cloud-Ordner wie Dropbox oder Google Drive, bekommst du automatisch Backups und die Möglichkeit, von verschiedenen Rechnern darauf zuzugreifen. Du könntest sogar noch einen Schritt weitergehen und ein bare Repo in die Cloud legen, das du dann lokal klonst - ich mach das mit meinen privaten Repos so.)

Git selbst hat keine Benutzerverwaltung. In den Commits werden einfach die Werte für Username und Email eingetragen, die ihr konfiguriert habt. Dass ihr alle den selben SSH-User zum Pushen benutzt, sollte aber kein Problem sein, da die Eintragung schon beim lokalen Committen statfindet und dann beim Pushen nicht mehr angefasst wird (das ist reine Spekulation ohne Gewähr :D).
 
1. In einem bare Repo hast du keinen Working Tree. Ganz einfach. Darin kannst du nicht arbeiten, das dient nur zur "Lagerung" bzw. Verteilung, ähnlich Github, Gitbucket und Co. In einem non-bare kannst du mit den Dateien arbeiten wie du lustig bist, sie modifizieren, löschen, hinzufügen, mergen, ... Geht nicht in nem bare Repo, denn dort hast du nur die Struktur von git selbst.

2. Erschließt sich vollständig aus Punkt 1.

3. Das entscheidet nur, wie die Commits aussehen, also welcher User was commited hat. Den Zugang über SSH musst du selbst regeln und hat mit git nichts zu tun.
 
Also ist es richtig, dass ich ein bare Reposiory für das gemeinsame Projekt angelegt habe.

Dann hätte ich nochmal 4 Folgefragen, wenns euch nicht zu viel wird :)

1. Das Repository für das gemeinsame Projekt ist ja dann richtig angelegt. Ich muss halt statt Pull einen Fetch machen, richtig?

2. In der Firma von meinem Praxissemester hatten wir auch für ein Softwareprojekt ein git Repository. Da konnte ich allerdings Pullen. Dann war das ja ein non-bare Repository, richtig? Wieso nutzen die dann ein non-bare Repository für gemeinsame Projekte? Ist das von denen dann falsch durchdacht?

3. Das Repository für die Bachelorarbeit kann ich aber auch bare machen, falls doch mal wer zweites dazu kommt oder?

4. @Nullpointer direkt: du schreibst, dass ich es am besten in einen Cloud Ordner reinpacken soll wegen des zusätzlichen Backups und den Zugriff von verschiedenen Rechnern. Aber das hab ich doch auch so oder? Auf meinen Webspace kann ich auch von versch. Rechnern zugreifen und vorallem macht doch git auch Backups von den verschiedenen alten Versionen? Oder meinst du falls mein Webspace ausversehen gelöscht wird wäre dann alles weg, was bei Dropbox nicht der Fall ist.
 
1. "git pull" ist einfach nur eine Abkürzung. Es macht erst "git fetch", um dein Repo mit dem Remote zu syncen, und bringt dann etwaige Änderungen in deinen gerade ausgecheckten Branch ein (mit "git merge" oder "git rebase", je nach Konfiguration).

2. Man kann auch non-bare Repos als "Zentralen" benutzen. Das bare Repo ist eben nur explizit dafür gedacht.

3. Siehe 2., außerdem: Sobald du auf dem Repo direkt arbeiten, also eine Arbeitskopie auschecken willst, muss das Repo non-bare sein.

4. Stimmt, wenn du auch das Repo für die Bachelorarbeit auf deinem Webspace hast, dann ist das so. (Dann kann das Repo auch bare sein, weil du es ohnehin lokal klonen musst.) Mein Tip bezog sich auf den Fall, dass du nur ein lokales Repo auf deiner Festplatte hast.

Edit: Erklärung zu bare vs. non-bare Repos
 
Abschließend, wenn du mir das mit ja beantwortest, dann hab ichs:

Ich lege nun das bare Repository für das gemeinsame Projekt auf meinem Webspace an. Hab dort Ordner, Programmcode etc. drin.

Dann clonen sich die verschiedenen Leute dieses Repository auf ihren PC, können daran entwickeln und checken dann ihre Änderungen ein.

Passt das?
 
Nicht ganz. In das bare Repository legst du nichts direkt hinein. Du klonst es auf deinem PC und committest dort deinen Code etc., dann pushst du es in das bare Repo.
 
Zurück
Oben