Git-Push/Pull zwischen den lokalen Repositories der Teammitglieder

Nehmen wir an, es gibt ein Team mit 4 Entwicklern. Wir haben auch ein zentrales Repository für unser Projekt. Entwickler pushen und pullen aus dem zentralen Repository. Hier(in Dezentral, aber zentral Abschnitt) heißt es, dass es möglich ist, lokale Repositories zwischen Teammitgliedern zu pushen/ziehen.

Jeder Entwickler zieht und schiebt zum Ursprung. Aber neben den zentralisierten Push-Pull-Beziehungen kann jeder Entwickler auch Änderungen von anderen Peers ziehen, um Unterteams zu bilden … Technisch bedeutet dies nichts anderes, als dass Alice eine Git-Fernbedienung namens bob definiert hat, die auf Bobs Repository zeigt, und vice umgekehrt

Nun stellt sich die Frage, wie man den entfernten Namen bob definiert, der auf Bobs Repository zeigt. Wenn es darauf ankommt, verwenden Entwickler möglicherweise unterschiedliche Betriebssysteme.

Wenn Sie ein Benutzerkonto auf dem Host einrichten und auf das Repo zugreifen, kann jemand anderes über SSH mit oder ohne Einrichtung einer benannten “Remote” pushen/abrufen.

git push user@host:/path/to/repo branch

Wenn Sie häufig Code freigeben, können Sie eine benannte Fernbedienung einrichten, um sich den Serverpfad zu merken:

git remote add remotename user@host:/path/to/repo

Wenn es in Ordnung ist, dass das Teilen eine enge Koordination (und wahrscheinlich sehr lockere Sicherheit) erfordert, können Sie eine kurzlebige starten git daemon auf dem “master” nach Bedarf: git-Äquivalent von ‘hg serve’? In diesem Fall gelten weiterhin die oben genannten Freigabebefehle, aber die user@host:/path wird ersetzt durch git://host/. Siehe auch Git-Daemon-Dokumentation.

Alternativ könnten Sie ein separates dediziertes Repository einrichten, das für die zwischenzeitliche Freigabe verwendet wird: Wie richte ich ein Staging-Repository in Git ein?

Es ist eine sehr häufige Sache wie Alice und Bob müssen gemeinsam an einigen Funktionen arbeiten. Inzwischen soll die Entwicklung auf unterschiedlichen Zweigen von unterschiedlichen Entwicklern durchgeführt werden.

Einfache Vorgehensweise wäre:

• Erstellen Sie einen neuen Zweig sprint_1, Alice und Bob checkout zu sprint_1
• Alle Änderungen in Bezug auf die Funktionalität sollten hier vorgenommen werden

• Push- und Pull-Operationen sollten mit durchgeführt werden

  git pull origin sprint_1  and git push origin sprint_1
  

Wenn die Änderungen abgeschlossen sind und sprint_1 einen stabilen Code hat, könnte er mit anderen Zweigen zusammengeführt werden. Wenn der Code auf sprint_1 einen langen Weg zurückgelegt hat, ist es ratsam, den Zweig neu zu gründen, anstatt zu fusionieren, um Konflikte oder Rosinenpickerei zu vermeiden.

Ähnlich wie GIT Clone Repo über das lokale Dateisystem in Windows

Per Antwort von JFSebastian:

$ git clone --no-hardlinks /path/to/repo

Der obige Befehl verwendet die POSIX-Pfadnotation für das Verzeichnis mit Ihrem Git-Repository. Für Windows ist es (Verzeichnis C:/path/to/repo enthält .git-Verzeichnis):

C:\some\dir\> git clone --local file:///C:/path/to/repo my_project

Das Repository wird nach C:\some\dir\my_project geklont. Wenn Sie den Teil file:/// weglassen, ist die Option –local impliziert.

Wenn sich die beiden Repos einen Dateisystem-Namespace teilen, können Sie einfach die Dateisystempfade direkt verwenden. Andernfalls können die Entwickler problemlos lokale Git-Server ausführen, z. B. auf einem VPN, auf dem der Zugriff bereits praktikabel privat ist git daemon Der Befehl liefert problemlos Abrufe, ansonsten können Sie den ssh-Zugriff auf einem dedizierten Port einrichten, um mit etwas mehr Arbeit den gleichen Effekt zu erzielen.

Ich wollte etwas Ähnliches tun, in meinem Fall suchte ich nach einer einfachen Möglichkeit, ein Projekt auf einem eingebetteten System (unter Linux) zu synchronisieren. Früher habe ich einfach eine gemeinsame Internetverbindung eingerichtet und aus dem zentralen Repository gezogen. Aber ich fand es nicht einfach, so zu arbeiten, und manchmal ist meine Internetverbindung einfach schlecht.

Im folgenden Artikel wird die Verwendung von git daemon wird sehr schön erklärt, um dieses Problem zu lösen. Ich werde hier nur eine kurze Kopie des Inhalts einfügen:
http://railsware.com/blog/2013/09/19/taming-the-git-daemon-to-quickly-share-git-repository/

Richten Sie die folgenden Aliase für den Lesezugriff (serve) oder den Lese-/Schreibzugriff (hub) auf Ihre Repositories ein:

$ git config --global alias.serve "!git daemon --base-path=. --export-all --reuseaddr --informative-errors --verbose"
$ git config --global alias.hub "!git daemon --base-path=. --export-all --enable=receive-pack --reuseaddr --informative-errors --verbose"

Dann auf dem Host einfach ausführen git serve oder git hub aus dem Verzeichnis, in dem sich die Repositorys befinden, die Sie freigeben möchten. Nun kann auf dem Client ausgeführt werden git clone git://x.x.x.x/path/to/repo um auf das lokale Repository auf dem Host zuzugreifen!

Für Windows-Benutzer:

• Verwenden Sie doppelte Anführungszeichen in den Befehlen, um die Aliase einzurichten
• Stellen Sie sicher, dass Sie die Eingabeaufforderung „aufhängen“, damit sie keine Zeile ausgibt, indem Sie mit der rechten Maustaste auf die Titelleiste klicken und Bearbeiten->Markieren wählen. Andernfalls könnten Verbindungen zu Clients aufgrund eines Fehlers in Git unterbrochen werden (laut einem Kommentar im Blogbeitrag).

TL;DR – Sie möchten die Schritte im Kapitel ausführen 4.4 für jede Maschine, die als Fernbedienung dient.

Wahres bekommen verteilter Arbeitsablauf ist nicht allzu schwierig, wenn Sie die Freiheit zwischen Ihrer Maschine und den Maschinen haben, mit denen Sie teilen möchten. Im Wesentlichen muss jede Maschine, die ein Repo bedient, als SSH-Git-Server fungieren.

Einige Antworten hier geben an, dass Sie einfach Benutzer zwischen den Computern hinzufügen und das Benutzerkennwort verwenden können, um SSH einzurichten. Kapitel 4.1 und 4.4 des Git-Buchs detailliert auch die Erstellung eines einzelnen Benutzers, der Zugriff auf Remote-Anfragen durch eine Liste von SSH-Schlüsseln in der gewährt ~/.ssh/authorized_keys Datei. Dies scheint ein netter konsolidierter Ansatz zum Verwalten des Zugriffs zu sein, der Ihren Kollegen gewährt wird, erfordert jedoch weiterhin das Verwalten von Benutzerschlüsseln in der Datei „authorized_keys“ für das Konsolidierungskonto. Etwas zu beachten, da dies “Ihre” Entwicklungsbox und kein richtiger “Server” ist.

Noch nie benutzt git daemon Ich kann nicht genau sagen, wie viel besser oder nicht es ist, aber es scheint eine praktikable Option zu sein, wenn Sie bereit sind, das zu verwenden git Protokoll, und haben Sie ein gutes Verständnis dafür, wie Sie es auf jeder Maschine ausführen, die ein Repository von einer sicheren Position in Ihrem Netzwerk aus bedienen soll. Es könnte hier auch hilfreich sein, darauf hinzuweisen, dass die Dokumentation Folgendes erwähnt, wenn auf Firewall-Einstellungen Bezug genommen wird:

Wenn Sie eine Firewall betreiben, müssen Sie an Port 9418 auf der Box, auf der Sie dies einrichten, auch ein Loch hineinschlagen