Wie stelle ich sicher, dass mein Git-Repo-Code sicher ist?

Question

Wenn unsere Organisation von einem zentralen Server-VCS wie Subversion zu einem verteilten VCS wie Git wechseln würde, wie stelle ich dann sicher, dass mein gesamter Code vor Hardwarefehlern geschützt ist?

Mit einem VCS auf einem zentralen Server muss ich nur jeden Tag ein Backup des Repositorys erstellen.Wenn wir ein DVCS verwenden würden, gäbe es auf allen Entwicklermaschinen jede Menge Codezweige, und wenn diese Hardware ausfallen würde (oder ein Entwickler seinen Laptop verlieren oder gestohlen werden würde), hätten wir keine Backups .

Beachten Sie, dass ich es nicht für eine gute Option halte, „die Entwickler dazu zu bringen, Zweige auf einen Server zu übertragen“ – das ist so langweilig und die Entwickler werden es am Ende nicht tun.

Gibt es einen gemeinsamen Weg, dieses Problem zu umgehen?

Einige Klarstellungen:

Dann mit einem nativ-zentralen Server-VCS alles muss sich auf dem zentralen Server befinden, mit Ausnahme der letzten Änderungen des Entwicklers.Wenn sich ein Entwickler beispielsweise für eine Verzweigung entscheidet, um einen Bugfix durchzuführen, befindet sich diese Verzweigung auf dem zentralen Server und ist sofort für die Sicherung verfügbar.

Wenn wir ein DVCS verwenden, kann der Entwickler eine lokale Verzweigung (und tatsächlich viele lokale Verzweigungen) erstellen.Keiner dieser Zweige befindet sich auf dem zentralen Server und steht für Backups zur Verfügung, bis der Entwickler denkt: „Oh ja, das sollte ich auf den zentralen Server übertragen.“

Der Unterschied, den ich sehe (korrigiert mich, wenn ich falsch liege!):Halb implementierte Funktionen und Bugfixes stehen wahrscheinlich nicht für die Sicherung auf dem zentralen Server zur Verfügung, wenn wir ein DVCS verwenden, wohl aber mit einem normalen VCS.Wie bewahre ich diesen Code sicher auf?

Answer 1

Ich denke, Sie werden feststellen, dass Entwickler in der Praxis lieber ein zentrales Repository verwenden, als zwischen den lokalen Repositorys des anderen zu pushen und zu ziehen.Sobald Sie ein zentrales Repository geklont haben, während Sie an Tracking-Zweigen arbeiten, sind das Abrufen und Pushen triviale Befehle.Das Hinzufügen eines halben Dutzend Remotes zu den lokalen Repositorys Ihrer Kollegen ist mühsam und diese Repositorys sind möglicherweise nicht immer zugänglich (ausgeschaltet, auf einem mit nach Hause genommenen Laptop usw.).

Wenn Sie alle an demselben Projekt arbeiten, muss irgendwann die gesamte Arbeit integriert werden.Das bedeutet, dass Sie einen Integrationszweig benötigen, in dem alle Änderungen zusammenlaufen.Dies muss natürlich an einem für alle Entwickler zugänglichen Ort erfolgen, es gehört beispielsweise nicht auf den Laptop des Hauptentwicklers.

Sobald Sie ein zentrales Repository eingerichtet haben, können Sie zum Einchecken und Aktualisieren einen Workflow im CVS/SVN-Stil verwenden.cvs update wird zu git fetch and rebase, wenn Sie lokale Änderungen haben, oder einfach zu git pull, wenn nicht.cvs commit wird zu git commit und git push.

Mit diesem Setup befinden Sie sich mit Ihrem vollständig zentralisierten VCS-System in einer ähnlichen Situation.Sobald Entwickler ihre Änderungen übermitteln (Git Push), was sie tun müssen, um für den Rest des Teams sichtbar zu sein, befinden sie sich auf dem zentralen Server und werden gesichert.

In beiden Fällen ist Disziplin erforderlich, um zu verhindern, dass Entwickler lang laufende Änderungen aus dem zentralen Repository fernhalten.Die meisten von uns haben wahrscheinlich schon einmal in einer Situation gearbeitet, in der ein Entwickler an der Funktion „x“ arbeitet, die eine grundlegende Änderung in einem Kerncode erfordert.Die Änderung wird dazu führen, dass alle anderen eine komplette Neuentwicklung durchführen müssen, aber die Funktion ist noch nicht für den Hauptstream bereit, sodass er sie einfach bis zu einem geeigneten Zeitpunkt überprüft.

Die Situation ist in beiden Situationen sehr ähnlich, obwohl es einige praktische Unterschiede gibt.Da Sie bei Verwendung von Git lokale Commits durchführen und den lokalen Verlauf verwalten können, empfindet der einzelne Entwickler möglicherweise nicht so stark die Notwendigkeit, in das zentrale Repository zu pushen wie bei etwas wie cvs.

Andererseits kann die Verwendung lokaler Commits als Vorteil genutzt werden.Es sollte nicht sehr schwierig sein, alle lokalen Commits an einen sicheren Ort im zentralen Repository zu verschieben.Lokale Zweige können in einem entwicklerspezifischen Tag-Namespace gespeichert werden.

Für Joe Bloggs könnte beispielsweise ein Alias ​​in seinem lokalen Repository erstellt werden, um als Reaktion auf (z. B.) Folgendes auszuführen: git mybackup.

git push origin +refs/heads/*:refs/jbloggs/*

Dies ist ein einzelner Befehl, der zu jedem Zeitpunkt (z. B. am Ende des Tages) verwendet werden kann, um sicherzustellen, dass alle seine lokalen Änderungen sicher gesichert werden.

Das hilft bei Katastrophen aller Art.Joes Maschine geht kaputt und er kann eine andere Maschine verwenden, die gespeicherten Commits abrufen und dort weitermachen, wo er aufgehört hat.Joe ist krank?Fred kann Joes Äste holen, um sich die „unverzichtbare“ Lösung zu holen, die er gestern gemacht hat, aber keine Chance hatte, sich mit dem Meister zu messen.

Um auf die ursprüngliche Frage zurückzukommen.Muss es einen Unterschied zwischen dVCS und zentralisiertem VCS geben?Sie sagen, dass halb implementierte Funktionen und Bugfixes im dVCS-Fall nicht im zentralen Repository landen, aber ich würde behaupten, dass es keinen Unterschied geben muss.

Ich habe viele Fälle gesehen, in denen eine halb implementierte Funktion bei der Verwendung von zentralisiertem VCS auf der Arbeitsbox eines Entwicklers verbleibt.Entweder ist eine Richtlinie erforderlich, die das Einchecken halb geschriebener Features in den Hauptstream ermöglicht, oder es muss die Entscheidung getroffen werden, einen zentralen Zweig zu erstellen.

Im dVCS kann dasselbe passieren, aber es sollte die gleiche Entscheidung getroffen werden.Wenn es sich um wichtige, aber unvollständige Arbeiten handelt, müssen diese zentral gespeichert werden.Der Vorteil von Git besteht darin, dass die Erstellung dieses zentralen Zweigs nahezu trivial ist.

Answer 2

Ich denke, es ist ein Irrtum ist, dass eine verteilte VCS notwendigerweise mit bedeutet, dass Sie muss es in einer vollständig verteilten Art und Weise nutzen. Es ist völlig gültig ein gemeinsames Git Repository einzurichten und alle zu sagen, dass Repository die offizielle ist. Für die normale Entwicklung Workflow würden Entwickler Änderungen aus dem gemeinsamen Repository ziehen und ihre eigenen Repositories aktualisieren. Nur im Falle von zwei Entwickler auf ein bestimmtes Feature aktiv zusammenarbeiten könnten sie brauchen Veränderungen ziehen direkt voneinander.

Mit mehr als ein paar Entwickler an einem Projekt arbeiten, es ernsthaft mühsam wäre, muss bedenken, sonst ziehen sie von allen. Was würden Sie tun, wenn Sie nicht haben ein zentrales Repository?

Bei der Arbeit haben wir eine Backup-Lösung, die alle sichert funktioniert Verzeichnisse täglich, und schreibt die ganze Menge auf eine DVD wöchentlich. Also, auch wenn wir ein zentrales Repository haben, jedes einzelne ist auch gesichert.

Answer 3

Es ist nicht ungewöhnlich, dass ein „zentralen“ Server als Autorität in DVCS zu verwenden, die den Ort bieten Ihnen auch Ihre Backups zu tun.

Answer 4

Ich finde diese Frage ein wenig seltsam zu sein. Angenommen, Sie sind ein nicht-verteiltes Versionskontrollsystem verwenden, wie CVS, haben Sie einen Repository auf dem zentralen Server und unfertigen auf Entwickler-Servern. Wie sichern Sie das Repository auf? Wie sichern Sie Entwickler unfertige up? Die Antwort auf diese Fragen ist genau das, was Sie Ihre Frage zu tun haben, zu behandeln.

verteilte Versionskontrolle, Repositories auf der Entwickler-Server sind gerade in Arbeit. Wollen Sie es sichern? zurück es dann nach oben! Es ist so einfach wie das.

Wir haben ein automatisiertes Backup-System, das alle Verzeichnisse aus unseren unsere Maschinen packt, die wir angeben, so füge ich alle Repositories und Arbeitskopien auf meinem Rechner zu diesem letzten, einschließlich der beiden git und CVS-Repositories.

By the way, wenn Sie die Versionskontrolle in einem Unternehmen verteilt sind, mit einem Produkt der Freigabe, dann Sie ein zentrales Repository haben. Es ist diejenige, die Sie aus freigeben. Es ist vielleicht nicht auf einem speziellen Server sein; es könnte auf einige Entwickler auf der Festplatte sein. Aber das gewünschte Archiv von Release ist das zentrale Repository. (Ich nehme an, wenn Sie nicht freigegeben haben, noch, Sie kein Konto haben könnte, noch nicht.) Ich bin ein bisschen das Gefühl, dass alle Projekte haben eine oder mehrere zentrale Repositories. (Und wirklich, wenn sie mehr als eine haben, ist es zwei Projekte und ist eine Gabel.) Die für Open Source geht auch.

Auch wenn Sie nicht ein zentrales Repository, ist die Lösung das gleiches haben: sichert die Arbeit an Entwickler-Maschinen. Sie sollten das sowieso getan. Die Tatsache, dass die laufenden Arbeiten in verteilten Repositories anstelle von CVS Arbeitskopien oder gerade Nonversioned Verzeichnissen geordneter Bedeutung ist.

Answer 5

Sie könnten Entwickler Home-Verzeichnisse montieren Remote-Geräte über das lokale Netzwerk. Dann müssen Sie nur noch darum, die Netzwerkspeicher sicher kümmern. Oder vielleicht könnten Sie so etwas wie verwenden DropBox Ihrem lokalen Repo kopieren an anderer Stelle nahtlos.

Answer 6

Alle Entwickler in Ihrem Team können ihre eigenen Filialen auf dem Server als auch (kann pro Ticket sein oder nur pro dev, etc). Auf diese Weise sie nicht brechen, den Bau in der Master-Zweig, aber sie immer noch ihre unfertigen an den Server zu schieben, die gesichert werden.

Mein eigenes git_remote_branch Werkzeug kann für diese Art von Workflow in praktisch, (Beachten sie, dass es erfordert Rubin). Es hilft Manipulation Fern Zweige.

Als Randbemerkung, im Gespräch über Repo-Sicherheit, auf dem Server, den Sie auf eine post-commit Haken festlegen können, macht ein einfaches git clone oder git push auf eine andere Maschine ... Sie erhalten Backup ein aktuelles nach jedem Commit !

Answer 7

Wir verwenden rsync für die Sicherung der einzelnen Entwickler .git Verzeichnisse in einem Verzeichnis auf dem Server. Dies ist Setup mit Wrapper-Skripten um git clone, und die post-commit usw. Haken.

Weil es in den post- * Haken erfolgt, Entwickler brauchen nicht zu vergessen, es manuell zu tun. Und weil wir rsync mit einem Timeout zu verwenden, wenn der Server abstürzt oder der Benutzer remote arbeiten, können sie immer noch funktionieren.