So führen Sie eine anwendungskonsistente Sicherung von Git-Repo durch

471
jia103

Stellen Sie sich vor, ich habe ein einfaches Git-Repository auf meinem eigenen gehosteten Server, das von mehreren Leuten zum Klonen, Pushing und Pulling verwendet wird. Welche Befehle wären erforderlich, um ein solches Repository in einen Zustand zu bringen, in dem es möglich ist, einen Snapshot auszuführen, wie im Link unten unter Bezugnahme auf eine anwendungskonsistente Sicherung beschrieben?

Ich stelle mir vor, ich brauche Git-Befehle für die folgenden Aufgaben beim Sperren:

  • Verbot von Pushs von anderen Benutzern.
  • Lassen Sie alle aktuell stattfindenden Pushs abschließen.

Ich stelle mir vor, ich brauche Git-Befehle für die folgenden Aufgaben beim Entsperren:

  • Wiederaufnahme von Push-Vorgängen von anderen Benutzern.

Ich habe die Unterschiede zwischen absturzkonsistenten Sicherungen und anwendungskonsistenten Sicherungen untersucht .

Es scheint, dass Anwendungskonsistenz für Anwendungen wie Datenbanken erforderlich ist, in denen eine gewisse Ruhezeit zusammen mit einem kontrollierten Sperren und Entsperren erforderlich ist, um die Anwendung in einen Zustand zu versetzen, in dem die Momentaufnahme ausgeführt werden kann.

Ich frage hier nicht, ob eine solche Aktivität für Git notwendig ist oder nicht. Ich denke, das ist eher eine Meinung als eine Tatsache.

Was ich hier frage, ist, welche Git-Befehle in welcher Reihenfolge erforderlich sind, um eine anwendungskonsistente Sicherung von Git-Repos auf einem Server zu unterstützen.

0

1 Antwort auf die Frage

0
Lazy Badger
  1. Git hat nicht haben keine Befehle zum Sperren | Entriegeln Workflow für Repository (da nur nicht dieses Modell als nicht unterstützt jede andere DVCS)
  2. Begriffe "* - konsistente Backups" (beide Formulare) gelten nicht für Repo-Daten - es handelt sich lediglich um Daten in einem bestimmten Zustand ... oder möglicherweise in einem beliebigen Zustand
  3. Git ist transaktionsbasiert, also gibt es keine "laufenden" Operationen, bis die vollständige Transaktion abgeschlossen ist
  4. Folge von 1-3: plain git clone| git pull(für neue | vorhandene Verzweigungen) reicht für Sie aus, um eine konsistente Sicherung für die HEAD-Revision (in time) des SRC-Repositorys zu erhalten

Verwandte Probleme