web-dev-qa-db-ger.com

Git und Dropbox effektiv zusammen nutzen?

Wie setze ich Git und Dropbox effektiv zusammen?

1109
n1kh1lp

Ich finde Git on Dropbox großartig. Ich benutze es die ganze Zeit. Ich habe mehrere Computer (zwei zu Hause und einen bei der Arbeit), auf denen ich Dropbox als zentrales nacktes Repository verwende. Da ich es nicht auf einem öffentlichen Dienst hosten möchte und keinen Zugriff auf einen Server habe, auf den ich immer ssh kann, erledigt Dropbox dies, indem ich es (sehr schnell) im Hintergrund synchronisiere.

Das Setup sieht ungefähr so ​​aus:

~/project $ git init
~/project $ git add .
~/project $ git commit -m "first commit"
~/project $ cd ~/Dropbox/git

~/Dropbox/git $ git init --bare project.git
~/Dropbox/git $ cd ~/project

~/project $ git remote add Origin ~/Dropbox/git/project.git
~/project $ git Push -u Origin master

Von dort aus können Sie einfach ~/Dropbox/git/project.git klonen, das Sie mit Ihrem Dropbox-Konto verknüpft haben (oder dieses Verzeichnis für andere freigegeben haben). Sie können alle normalen Git-Vorgänge ausführen und diese werden automatisch mit allen Ihren anderen Computern synchronisiert.

Ich schrieb einen Blog-Beitrag, On Version Control, ( alter Link tot) auf meine Überlegungen und wie ich meine Umgebung einrichte, basiert es auf meiner Ruby on Rails Entwicklungserfahrung, kann aber wirklich auf alles angewendet werden.

1376
Dan McNevin

Der richtige Weg dazu ist die Verwendung von git-remote-dropbox: https://github.com/anishathalye/git-remote-dropbox

Das Erstellen eines eigenen Bare-Repos in Dropbox bereitet viele Probleme. Anish (der Schöpfer der Bibliothek) erklärt es am besten :

Die Hauptursache für diese Probleme ist, dass der Dropbox-Desktop-Client zum Synchronisieren von Dateien und nicht von Git-Repositorys entwickelt wurde. Ohne spezielle Behandlung für Git-Repositorys werden nicht die gleichen Garantien wie für Git beibehalten. Vorgänge auf dem Remote-Repository sind nicht mehr unteilbar, und gleichzeitige Vorgänge oder ein unglückliches Timing bei der Synchronisierung können zu einem beschädigten Repository führen.

Traditionelle Git-Remotes führen den Code auf der Serverseite aus, damit dies ordnungsgemäß funktioniert. Dies ist jedoch nicht möglich.

Lösung: Es ist möglich, dies richtig zu lösen. Es ist möglich, Git mit Dropbox zu verwenden und die gleichen Sicherheits- und Konsistenzgarantien wie bei einer herkömmlichen Git-Fernbedienung zu erhalten, auch wenn mehrere Benutzer gleichzeitig aktiv sind.

Für einen Benutzer ist es so einfach wie die Verwendung von git-remote-dropbox, einem Git-Remote-Helfer, der als transparente bidirektionale Brücke zwischen Git und Dropbox fungiert und alle Garantien einer herkömmlichen Git-Remote beibehält. Die Verwendung mit freigegebenen Ordnern ist sogar sicher, sodass sie für die Zusammenarbeit verwendet werden kann (yay unbegrenzte private Repos mit unbegrenzten Mitarbeitern!).

Mit dem Remote-Helfer ist es möglich, Dropbox als Git-Remote zu verwenden und weiterhin alle regulären Git-Befehle wie git clone, git pull und git Push zu verwenden, und alles funktioniert wie erwartet.

116
clu

Diese Antwort basiert auf der Erfahrung Mercurial , nicht auf Git, aber diese Erfahrung besagt, dass die Verwendung von Dropbox auf diese Weise nach beschädigten Repositorys fragt, wenn sogar die Möglichkeit besteht, dass Sie dasselbe Dropbox-basierte Repository von einem anderen aktualisieren Maschinen zu verschiedenen Zeiten (Mac, Unix, Windows in meinem Fall).

Ich habe keine vollständige Liste der Dinge, die schief gehen können, aber hier ist ein konkretes Beispiel, das mich gebissen hat. Jede Maschine hat ihre eigene Vorstellung von Zeilenendezeichen und wie Groß-/Kleinbuchstaben in Dateinamen behandelt werden. Dropbox und Git/Mercurial gehen damit etwas anders um (ich erinnere mich nicht an die genauen Unterschiede). Wenn Dropbox das Repository hinter Git/Mercurials defektem Repository aktualisiert. Dies geschieht sofort und unsichtbar, sodass Sie nicht einmal wissen, dass Ihr Repository beschädigt ist, bis Sie versuchen, etwas daraus wiederherzustellen.

Nachdem ich aus einem Durcheinander herausgegraben habe, habe ich das folgende Rezept mit großem Erfolg und ohne Anzeichen von Problemen verwendet. Verschieben Sie einfach Ihr Repository aus Dropbox. Verwenden Sie Dropbox für alles andere. Dokumentation, JAR-Dateien , alles, was Sie wollen. Verwenden Sie GitHub (Git) oder Bitbucket (Mercurial), um das Repository selbst zu verwalten. Beide sind kostenlos, was die Kosten nicht erhöht, und jedes Werkzeug spielt jetzt seine Stärken aus.

Wenn Sie Git/Mercurial über Dropbox ausführen, wird nur das Risiko erhöht. Tu es nicht.

89
Bradjcox

Ich wollte nicht alle meine Projekte unter einem Git-Repository ablegen, noch wollte ich diesen Code für jedes einzelne Projekt ausführen, also habe ich ein Bash -Skript erstellt, das den Prozess automatisiert. Sie können es in einem oder mehreren Verzeichnissen verwenden - so kann es den Code in diesem Beitrag für Sie ausführen oder es kann es in mehreren Projekten gleichzeitig ausführen.

#!/bin/sh
# Script by Eli Delventhal
# Creates Git projects for file folders by making the Origin Dropbox. You will need to install Dropbox for this to work.

# Not enough parameters, show help.
if [ $# -lt 1 ] ; then

cat<<HELP
projects_to_git.sh -- Takes a project folder and creates a Git repository for it on Dropbox

USAGE:
    ./projects_to_git.sh file1 file2 ..

EXAMPLES:
    ./projects_to_git.sh path/to/MyProjectDir
        Creates a git project called MyProjectDir on Dropbox

    ./projects_to_git.sh path/to/workspace/*
        Creates a git project on Dropbox for every folder contained within the workspace directory, where the project name matches the folder name

HELP
    exit 0
fi

# We have enough parameters, so let's actually do this thing.

START_DIR=$(pwd)

# Make sure we have a connection to Dropbox
cd ~
if [ -s 'Dropbox' ] ; then
    echo "Found Dropbox directory."
    cd Dropbox
    if [ -s 'git' ] ; then
        echo "    Dropbox Git directory found."
    else
        echo "    Dropbox Git directory created."
        mkdir git
    fi
else
    echo "You do not have a Dropbox folder at ~/Dropbox! Install Dropbox. Aborting..."
    exit 0
fi

# Process all directories matching the passed parameters.
echo "Starting processing for all files..."
for PROJ in $*
do
    if [ -d $PROJ ] ; then
        PROJNAME=$(basename $PROJ)
        echo "  Processing $PROJNAME..."

        # Enable Git with this project.
        cd $PROJ
        if [ -s '.git' ] ; then
            echo "    $PROJNAME is already a Git repository, ignoring..."
        else
            echo "    Initializing Git for $PROJNAME..."
            git init -q
            git add .
            git commit -m "Initial creation of project." -q

            # Make the Origin Dropbox.

            cd ~/Dropbox/git
            if [ -s $PROJNAME ] ; then
                echo "    Warning! $PROJNAME already exists in Git! Ignoring..."
            else
                echo "    Putting $PROJNAME project on Dropbox..."
                mkdir $PROJNAME
                cd $PROJNAME
                git init -q --bare
            fi

            # Link the project to the Origin
            echo "    Copying local $PROJNAME to Dropbox..."
            cd $PROJ
            git remote add Origin "~/Dropbox/git/$PROJNAME"
            git Push -q Origin master
            git branch --set-upstream master Origin/master
        fi
    fi
done

echo "Done processing all files."
cd $START_DIR
16
Eli

In Bezug auf kleine Teams, die Dropbox verwenden:

Wenn jeder Entwickler sein eigenes, beschreibbares, unbeschriebenes Repository auf Dropbox hat, was nur Pull für andere Entwickler ist, erleichtert dies die gemeinsame Nutzung von Code, ohne dass das Risiko einer Beschädigung besteht!

Wenn Sie dann eine zentralisierte "Hauptlinie" wünschen, können Sie einen Entwickler alle Pushs von seinem eigenen Repo aus verwalten lassen.

16
teh_senaus

Ich denke nicht, dass die Verwendung von Git und Dropbox der richtige Weg ist ... Denken Sie nur an die Funktionen von beiden:

Git:

  • Ermöglicht es Ihnen, ein zentrales Repository zu haben
  • Ermöglicht es Ihnen, Ihr eigenes Repository mit Ihren eigenen Änderungen zu haben
  • Ermöglicht das Senden und Empfangen von Änderungen aus dem zentralen Repository
  • Ermöglicht mehreren Personen, die gleichen Dateien zu ändern und sie zusammenzuführen, oder fordert Sie auf, sie zusammenzuführen, wenn dies nicht möglich ist
  • Verfügt über Web- und Desktop-Clients, um den Zugriff auf das zentrale Repository zu ermöglichen

Dropbox:

  • Bewahrt alles in einem zentralen Repository auf
  • Ermöglicht es Ihnen, Ihre eigenen Versionen der Dateien auf dem Server zu haben
  • Erzwingt das Senden und Empfangen von Änderungen aus dem zentralen Repository
  • Wenn mehrere Personen die gleichen Dateien ändern, wird die erste festgeschriebene Datei durch spätere Festschreibungen ersetzt, und es findet keine Zusammenführung statt, was mühsam ist (und definitiv den größten Nachteil darstellt).
  • Verfügt über Web- und Desktop-Clients, um den Zugriff auf das zentrale Repository zu ermöglichen.

Und wenn Sie sich Sorgen machen, einige Ihrer Dateien weiterzugeben, warum verschlüsseln Sie sie nicht? Und dann könnten Sie den größten Vorteil von Dropbox zu Git bekommen, nämlich öffentliche und private Dateien zu haben ...

15
Coyote21

Es ist jetzt 2015 und seit drei Tagen ist ein neues Tool basierend auf Dropbox API v2 erstellt worden, um Git auf Dropbox sicher zu verwenden. Es arbeitet mit der API und nicht mit dem Desktop-Client und verarbeitet mehrere gleichzeitige Pushs an ein Repository, das sich in einem freigegebenen Ordner befindet.

Einmal konfiguriert, erlaubt es einem, eine Git-Fernbedienung genau wie jede andere Git-Fernbedienung einzurichten.

git clone "dropbox::/path/to/repo"
git remote add Origin "dropbox::/path/to/repo"
15
merlin2011

Ich verwende Mercurial (oder Git) + TrueCrypt + Dropbox für verschlüsselte Remote-Sicherungen .

Das Coolste ist, dass Dropbox NICHT den gesamten TrueCrypt-Container synchronisiert, wenn Sie einen kleinen Teil Ihres Codes ändern. Die Synchronisationszeit ist in etwa proportional zur Anzahl der Änderungen. Obwohl verschlüsselt, nutzt die Kombination von TrueCrypt + Dropbox die Blockverschlüsselung + Blockebenensynchronisierung hervorragend.

Zweitens erhöht ein monolithisch verschlüsselter Container nicht nur die Sicherheit, sondern verringert auch die Wahrscheinlichkeit eines Repository Beschädigung .

Achtung: Sie müssen jedoch sehr vorsichtig sein, damit der Container nicht montiert wird, während Dropbox ausgeführt wird. Es kann auch schwierig sein, Konflikte zu lösen, wenn zwei verschiedene Clients unterschiedliche Versionen in den Container einchecken. Daher ist es nur für eine einzelne Person praktisch, die es für Backups verwendet, nicht für ein Team.

Konfiguration:

  • Erstellen Sie einen Truecrypt-Container (mehrere Gigabyte sind in Ordnung)
  • Deaktivieren Sie unter Truecrypt-Einstellungen die Option preserve modification timestamp *.
  • Erstellen Sie ein Repo wie oben von Dan erwähnt ( https://stackoverflow.com/a/1961515/781695 )

Verwendungszweck:

  • Beenden Sie Dropbox
  • Montieren Sie den Container. Verschieben Sie Ihre Änderungen und heben Sie die Montage auf
  • Führen Sie Dropbox aus

P.S. Durch Deaktivieren von preserve modification timestamp wird Dropbox mitgeteilt, dass die Datei geändert wurde und synchronisiert werden soll. Beachten Sie, dass das Mounten des Containers den Zeitstempel ändert, auch wenn Sie keine Datei darin ändern. Wenn das nicht passieren soll, mounten Sie das Volume einfach als read-only

9
user

Ich habe Mercurial in der empfohlenen Weise verwendet und fordere Sie auf, vorsichtig zu sein, insbesondere, wenn sich die Maschinen unterscheiden. Die Dropbox-Foren sind voll von Beschwerden über mysteriöse Probleme mit Dateinamen, die spontan auftauchen. Hg (und ich nehme an, Git) bemerkt oder beschwert sich bei Routine-Checkins nicht und Sie werden nur dann von der Korruption hören, wenn es sich über ein korruptes Repo beschwert, wenn Sie versuchen, es für echt zu verwenden. Schlechte Nachrichten. Ich wünschte, ich könnte genauer auf das Problem und seine Problemumgehungen eingehen. Ich versuche immer noch, mich von diesem Durcheinander zu befreien.

6
Brad Cox

Ich liebe die Antwort von Dan McNevin! Ich verwende jetzt auch Git und Dropbox zusammen und verwende mehrere Aliase in meinem . Bash_profile , sodass mein Workflow so aussieht:

~/project $ git init
~/project $ git add .
~/project $ gcam "first commit"
~/project $ git-dropbox

Dies sind meine Pseudonyme:

alias gcam='git commit -a -m'
alias gpom='git Push Origin master'
alias gra='git remote add Origin'
alias git-dropbox='TMPGP=~/Dropbox/git/$(pwd | awk -F/ '\''{print $NF}'\'').git;mkdir -p $TMPGP && (cd $TMPGP; git init --bare) && gra $TMPGP && gpom'
6
Michiel de Mare

Es gibt auch ein Open-Source-Projekt (eine Sammlung von plattformübergreifenden [Linux, Mac, Win] -Skripten), das alle wichtigen Details der Repository-Verwaltung mit einer Handvoll (3-4) Befehlen ausführt.

https://github.com/karalabe/gitbox/wiki

Beispielnutzung ist:

$ gitbox create myapp
Creating empty repository...
Initializing new repository...
Repository successfully created.

$ gitbox clone myapp
Cloning repository...
Repository successfully cloned.

Nach welcher normalen Git-Nutzung:

$ echo “Some change” > somefile.txt
$ git add somefile.txt
$ git commit –m “Created some file”
$ git Push

Überprüfen Sie das Projekt-Wiki und die Handbücher auf vollständige Befehlsreferenzen und Tutorials.

5

Wir verwenden diese Methode (Erstellen eines nackten Repositorys in Dropbox) auf einem Freigabeordner.

Eine kleine Gruppe von Entwicklern kann aus diesem synchronisierten Repository einen lokalen Klon erstellen. Sobald die Arbeitseinheit fertig ist, kehren wir zu Origin zurück.

Eine Sache, die ich vermisse, ist eine gute Möglichkeit, eine E-Mail mit den Informationen zum Änderungssatz zu senden, sobald ein Push-to-Origin-Vorgang stattfindet. Wir verwenden Google Wave, um Änderungen manuell nachzuverfolgen.

5
dengel

Ich speichere meine Nicht-Github-Repos auf Dropbox. Eine Einschränkung, auf die ich gestoßen bin, war die Synchronisierung nach einer Neuinstallation. Dropbox lädt zuerst die kleinsten Dateien herunter, bevor es zu den größeren übergeht. Kein Problem, wenn Sie nachts anfangen und nach dem Wochenende wiederkommen :-)

Mein Thread - http://forums.dropbox.com/topic.php?id=29984&replies=6

4
Ben

Die von Dan McNevin am häufigsten gewählte Antwort gefällt mir. Ich habe die Abfolge der Git-Befehle zu oft ausgeführt und mich dazu entschlossen, ein Skript zu erstellen. Hier ist es also:

#!/bin/bash

# Usage
usage() {
    echo "Usage: ${0} -m [ master-branch-directory ] -r [ remote-branch-directory ] [ project-name ]"
    exit 1
}

# Defaults
defaults() {
    masterdir="${HOME}/Dropbox/git"
    remotedir="${PWD}"
    gitignorefile="# OS generated files #\n\n.DS_Store\n.DS_Store?\n.Spotlight-V100\n.Trashes\nehthumbs.db\nThumbs.db"
}

# Check if no arguments
if [ ${#} -eq 0 ] ; then
    echo "Error: No arguments specified"
    usage
fi

#Set defaults
defaults

# Parse arguments
while [ ${#} -ge 1 ]; do
    case "${1}" in
        '-h' | '--help' ) usage ;;
        '-m' )
            shift
            masterdir="${1}"
            ;;
        '-r' )
            shift
            remotedir="${1}"
            ;;
        * )
            projectname="${1##*/}"
            projectname="${projectname%.git}.git"
            ;;
    esac
    shift
done

# check if specified directories and project name exists
if [ -z "${projectname}" ]; then
    echo "Error: Project name not specified"
    usage
fi

if [ ! -d "${remotedir}" ]; then
    echo "Error: Remote directory ${remotedir} does not exist"
    usage
fi

if [ ! -d "${masterdir}" ]; then
    echo "Error: Master directory ${masterdir} does not exist"
    usage
fi

#absolute paths
remotedir="`( cd \"${remotedir}\" && pwd )`"
masterdir="`( cd \"${masterdir}\" && pwd )`"

#Make master git repository
cd "${masterdir}"
git init --bare "${projectname}"

#make local repository and Push to master
cd "${remotedir}"
echo -e "${gitignorefile}" > .gitignore # default .gitignore file
git init
git add .
git commit -m "first commit"
git remote add Origin "${masterdir}/${projectname}"
git Push -u Origin master

#done
echo "----- Locations -----"
echo "Remote branch location: ${remotedir}"
echo "Master branch location: ${masterdir}"
echo "Project Name: ${projectname}"

Das Skript benötigt nur einen Projektnamen. Es wird ein Git-Repository in ~/Dropbox/git/ unter dem angegebenen Namen erstellt und der gesamte Inhalt des aktuellen Verzeichnisses in den neu erstellten Origin-Hauptzweig verschoben. Wenn mehr als ein Projektname angegeben wird, wird das am weitesten rechts stehende Argument für den Projektnamen verwendet.

Optional gibt das Befehlsargument -r den Remote-Zweig an, der an den Origin-Master weitergeleitet wird. Der Speicherort des Origin-Masters des Projekts kann auch mit dem Argument -m angegeben werden. Eine Standarddatei mit der Erweiterung .gitignore wird ebenfalls im Remote-Zweigstellenverzeichnis abgelegt. Die Standardeinstellungen für Verzeichnis und .gitignore-Datei werden im Skript angegeben.

3
ChisholmKyle

Jetzt im Jahr 2014 benutze ich Git und Dropbox seit ungefähr eineinhalb Jahren ohne Probleme. Einige Punkte jedoch:

  • Alle meine Maschinen, die Dropbox benutzen, sind unter Windows, verschiedene Versionen (7 bis 8) + 1 Mac.
  • Ich teile das Repository nicht mit anderen, daher bin ich der einzige, der es ändert.
  • git Push verschiebt sich in ein Remote-Repository, sodass ich es leicht wiederherstellen kann, falls es jemals beschädigt wird.
  • Ich musste Aliase in C:\Users mit mklink /D link target erstellen, da einige Bibliotheken auf absolute Positionen verweisen.
3
Mikaël Mayer

Ein anderer Ansatz:

Alle bisherigen Antworten, einschließlich @ Dan answer , beziehen sich auf die Idee, Dropbox zur Zentralisierung eines gemeinsam genutzten Repositorys zu verwenden, anstatt einen Dienst zu verwenden, der sich auf Git wie Github, Bitbucket usw. konzentriert.

Da in der ursprünglichen Frage jedoch nicht angegeben ist, was es bedeutet, "Git und Dropbox effektiv zusammen zu verwenden", sollten wir einen anderen Ansatz wählen: "Dropbox nur zum Synchronisieren des Arbeitsbaums verwenden."

Das How-to hat diese Schritte:

  1. im Projektverzeichnis wird ein leeres Verzeichnis _.git_ erstellt (z. B. _mkdir -p myproject/.git_).

  2. heben Sie die Synchronisierung des Verzeichnisses _.git_ in Dropbox auf. Wenn Sie die Dropbox-App verwenden: Gehen Sie zu "Einstellungen", "Synchronisieren" und "Zu synchronisierende Ordner auswählen", wobei das Verzeichnis "_.git_" deaktiviert werden muss. Dadurch wird das Verzeichnis _.git_ entfernt.

  3. führen Sie _git init_ im Projektverzeichnis aus

Es funktioniert auch, wenn _.git_ bereits vorhanden ist. Führen Sie dann nur Schritt 2 aus. Dropbox speichert jedoch eine Kopie der Git-Dateien auf der Website.

Schritt 2 bewirkt, dass Dropbox die Git-Systemstruktur nicht synchronisiert. Dies ist das gewünschte Ergebnis für diesen Ansatz.

Warum sollte man diesen Ansatz verwenden?

  • Die noch nicht übertragenen Änderungen haben eine Dropbox-Sicherung und werden geräteübergreifend synchronisiert.

  • Für den Fall, dass Dropbox beim Synchronisieren zwischen Geräten etwas kaputt macht, sind _git status_ und _git diff_ praktisch, um die Probleme zu lösen.

  • Es spart Platz im Dropbox-Konto (der gesamte Verlauf wird dort nicht gespeichert)

  • Es vermeidet die Bedenken, die @dubek und @Ates in den Kommentaren zu @Dans Antwort geäußert haben, und die Bedenken von @clu in eine andere Antwort .

Das Vorhandensein einer Fernbedienung an einem anderen Ort (Github usw.) funktioniert mit diesem Ansatz einwandfrei.

Die Arbeit an verschiedenen Branchen bringt einige Probleme mit sich, die behoben werden müssen:

  • Ein mögliches Problem besteht darin, dass Dropbox (unnötigerweise?) Möglicherweise viele Dateien synchronisiert, wenn verschiedene Zweige ausgecheckt werden.

  • Wenn auf zwei oder mehr synchronisierten Dropbox-Geräten unterschiedliche Zweige ausgecheckt sind, können nicht festgeschriebene Änderungen an beiden Geräten verloren gehen.

Eine Möglichkeit, diese Probleme zu umgehen, besteht darin, git worktree zu verwenden, um das Auschecken von Zweigen in separaten Verzeichnissen zu speichern.

2
IBrum

Ich habe ein ähnliches Problem und habe ein kleines Skript für das gleiche erstellt. Die Idee ist, Dropbox mit Git so einfach wie möglich zu benutzen. Derzeit habe ich Ruby Code schnell implementiert und werde demnächst weitere hinzufügen.

Das Skript kann unter https://github.com/nuttylabs/box-git aufgerufen werden.

2
Kiran Madipally

Für meine 2 Cent macht Dropbox nur Sinn für den persönlichen Gebrauch, wo Sie sich nicht die Mühe machen wollen, einen zentralen Repo-Host zu bekommen. Für jede berufliche Entwicklung werden Sie wahrscheinlich mehr Probleme erstellen, als Sie lösen werden, wie bereits mehrmals im Thread erwähnt wurde. Dropbox ist nicht für diesen Anwendungsfall konzipiert. Allerdings ist die Verwendung von Bundles eine absolut sichere Methode, um Repositorys auf Dropbox ohne Plugins oder Tools von Drittanbietern zu sichern. Ich habe die folgenden Aliase in meinem .gitconfig, um die Eingabe zu speichern:

[alias]
        bundle-Push = "!cd \"${GIT_PREFIX:-.}\" && if path=\"$(git config remote.\"$1\".url)\" && [ \"${path:0:1}\" = / ]; then git bundle create \"$path\" --all && git fetch \"$1\"; else echo \"Not a bundle remote\"; exit 1; fi #"
        bundle-fetch = "!cd \"${GIT_PREFIX:-.}\" && if path=\"$(git config remote.\"$1\".url)\" && [ \"${path:0:1}\" = / ]; then git bundle verify \"$path\" && git fetch \"$1\"; else echo \"Not a bundle remote\"; exit 1; fi #"
        bundle-new = "!cd \"${GIT_PREFIX:-.}\" && if [ -z \"${1:-}\" -o -z \"${2:-}\" ]; then echo \"Usage: git bundle-new <file> <remote name>\"; exit 1; Elif [ -e \"$2\" ]; then echo \"File exist\"; exit 1; else git bundle create \"$2\" --all && git remote add -f \"$1\" \"$(realpath \"$2\")\"; fi #"

Beispiel:

# Create bundle remote (in local repo)
$ git bundle-new dropbox ~/Dropbox/my-repo.bundle
# Fetch updates from dropbox
$ git bundle-fetch dropbox
# NOTE: writes over previous bundle. Thus, roughly equivalent to Push --force --Prune --all
$ git bundle-Push
2
Niklas Holm

Ohne die Verwendung von Integrationstools von Drittanbietern könnte ich den Zustand ein wenig verbessern und DropBox und andere ähnliche Cloud-Festplattendienste wie SpiderOak mit Git verwenden.

Das Ziel ist es, die Synchronisation in der Mitte dieser Dateiänderungen zu vermeiden, da sie einen Teilstatus hochladen und dann wieder herunterladen kann, wodurch Ihr Git-Status vollständig beschädigt wird.

Um dieses Problem zu vermeiden, habe ich Folgendes getan:

  1. Bündeln Sie meinen Git-Index in einer Datei mit git bundle create my_repo.git --all.
  2. Stellen Sie eine Verzögerung für die Dateiüberwachung ein, z. B. 5 Minuten, anstatt sofort. Dies verringert die Wahrscheinlichkeit, dass DropBox einen Teilstatus während einer Änderung synchronisiert. Dies ist auch sehr hilfreich, wenn Sie Dateien auf der Cloud-Festplatte im laufenden Betrieb ändern (z. B. beim sofortigen Speichern von Apps zum Aufzeichnen von Notizen).

Es ist nicht perfekt, da es keine Garantie gibt, dass es den Git-Zustand nicht wieder durcheinander bringt, aber es hilft und im Moment habe ich kein Problem bekommen.

0
gaborous