Git und Dropbox effektiv zusammen nutzen?

Wie nutze ich Git und Dropbox effektiv zusammen?

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), die ich Dropbox als zentrales reines Repository verwende. Da ich es nicht in einem öffentlichen Dienst hosten möchte und keinen Zugriff auf einen Server habe, auf den ich immer ssh kann, kümmert sich Dropbox darum, indem es (sehr schnell) im Hintergrund synchronisiert.

Setup ist ungefähr so:

~/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 klonen, ~/Dropbox/git/project.gitdass Sie Ihrem Dropbox-Konto zugeordnet sind (oder dieses Verzeichnis für andere Personen freigegeben haben). Sie können alle normalen Git-Vorgänge ausführen und diese werden automatisch mit all Ihren anderen Computern synchronisiert.

Ich habe einen Blog-Beitrag über die Versionskontrolle ( alter Link ^tot ) über meine Überlegungen und die Einrichtung meiner Umgebung geschrieben. Er basiert auf meiner Erfahrung mit der Entwicklung von Ruby on Rails , kann aber wirklich auf alles angewendet werden.

Der richtige Weg, dies zu tun, ist die Verwendung von git-remote-dropbox: https://github.com/anishathalye/git-remote-dropbox

Das Erstellen eines eigenen Repos in Dropbox verursacht 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 ausgelegt ist. Ohne spezielle Behandlung für Git-Repositorys werden nicht die gleichen Garantien wie für Git beibehalten. Vorgänge im Remote-Repository sind nicht mehr atomar, und gleichzeitige Vorgänge oder unglückliches Timing bei der Synchronisierung können zu einem beschädigten Repository führen.

Herkömmliche Git-Fernbedienungen führen Code auf der Serverseite aus, damit dies ordnungsgemäß funktioniert, aber das können wir nicht.

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 haben, selbst wenn mehrere Benutzer gleichzeitig arbeiten!

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 gewährleistet. Die Verwendung mit freigegebenen Ordnern ist sogar sicher, sodass sie für die Zusammenarbeit verwendet werden können (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-Klon, Git-Pull und Git-Push zu verwenden. Alles funktioniert wie erwartet.

Diese Antwort basiert auf der Mercurial- Erfahrung, nicht auf Git. Diese Erfahrung besagt jedoch, dass bei der Verwendung von Dropbox auf diese Weise nach beschädigten Repositorys gefragt wird, wenn überhaupt die Möglichkeit besteht, dass Sie dasselbe Dropbox-basierte Repository zu verschiedenen Zeiten von verschiedenen Computern aus aktualisieren (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 behandeln dies etwas anders (ich erinnere mich nicht an die genauen Unterschiede). Wenn Dropbox das Repository hinter Git / Mercurials Rücken aktualisiert, ist das Repository bereits beschädigt. 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 herausgearbeitet 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.

Das Ausführen von Git / Mercurial auf Dropbox fügt nichts außer dem Risiko hinzu. Tu es nicht.

In Bezug auf kleine Teams, die Dropbox verwenden:

Wenn jeder Entwickler sein eigenes beschreibbares Bare-Repository auf Dropbox hat, das nur für andere Entwickler verfügbar ist, erleichtert dies die gemeinsame Nutzung von Code ohne das Risiko einer Beschädigung!

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

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, sodass es den Code in diesem Beitrag für Sie oder für mehrere Projekte gleichzeitig ausführen kann.

#!/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

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 Ihnen ein zentrales Repository
• Ermöglicht Ihnen ein eigenes Repository mit Ihren eigenen Änderungen
• Ermöglicht das Senden und Empfangen von Änderungen aus dem zentralen Repository
• Ermöglicht mehreren Personen, dieselben 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:

• Hält alles in einem zentralen Repository
• 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 dieselben Dateien ändern, wird die erste festgeschriebene Datei durch spätere Festschreibungen ersetzt, und es erfolgt keine Zusammenführung, was problematisch 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 Bedenken haben, einige Ihrer Dateien freizugeben, warum sollten Sie sie nicht verschlüsseln? Und dann könnten Sie den größten Vorteil von Dropbox für Git nutzen, nämlich öffentliche und private Dateien zu haben ...

Es ist jetzt 2015 und seit drei Tagen wurde ein neues Tool basierend auf Dropbox API v2 erstellt, um git auf Dropbox sicher zu verwenden. Es funktioniert gegen die API, anstatt den Desktop-Client zu verwenden, und verarbeitet mehrere gleichzeitige Pushs in ein Repository, das in einem freigegebenen Ordner gehostet wird, korrekt.

Einmal konfiguriert, kann man eine Git-Fernbedienung genau wie jede andere Git-Fernbedienung einrichten.

git clone "dropbox::/path/to/repo"
git remote add origin "dropbox::/path/to/repo"

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

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

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

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. Es ist also nur für eine einzelne Person praktisch, die es für Backups verwendet, nicht für ein Team.

Installieren:

• Erstellen Sie einen Truecrypt-Container (mehrere Gigabyte sind in Ordnung)
• Deaktivieren Sie unter Truecrypt-Einstellungen 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, schieben Sie Ihre Änderungen, entfernen Sie die Montage
• Führen Sie die Dropbox aus

PS Deaktivieren Sie das Kontrollkästchen "Tells" preserve modification timestamp, dass die Datei geändert wurde und synchronisiert werden soll. Beachten Sie, dass durch das Mounten des Containers der Zeitstempel geändert wird, auch wenn Sie keine Datei darin ändern. Wenn Sie dies nicht möchten, mounten Sie das Volume einfach alsread-only

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 folgendermaßen aussieht:

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

Das sind meine Aliase:

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'

Wir verwenden diese Methode (Erstellen eines Bare-Repositorys in Dropbox) für einen Freigabeordner .

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

Eine Sache, die mir fehlt, ist eine gute Möglichkeit, eine E-Mail mit den Änderungssatzinformationen zu senden, sobald ein Push-to-Origin erfolgt. Wir verwenden Google Wave, um Änderungen manuell zu verfolgen.

Ich habe Mercurial in der empfohlenen Weise verwendet und fordere Sie auf, vorsichtig zu sein, insbesondere wenn sich eine der Maschinen unterscheidet. Die Dropbox-Foren sind voll von Beschwerden über mysteriöse Probleme mit Dateinamen, die spontan auftauchen. Hg (und ich nehme an, Git) wird es beim routinemäßigen Einchecken nicht bemerken oder sich beschweren, und Sie werden nur dann von der Beschädigung hören, wenn es sich über ein beschädigtes Repo beschwert, wenn Sie versuchen, es wirklich zu verwenden. Schlechte Nachrichten. Ich wünschte, ich könnte genauer auf das Problem und seine Problemumgehungen eingehen. Ich versuche immer noch, selbst aus diesem Chaos herauszukommen.

Es gibt auch ein Open-Source-Projekt (eine Sammlung plattformübergreifender Skripte [Linux, Mac, Win]), das alle 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.

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

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

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

• Alle meine Computer, die Dropbox verwenden, sind unter Windows, verschiedene Versionen (7 bis 8) + 1 Mac.
• Ich teile das Repository nicht mit jemand anderem, daher bin ich der einzige, der es ändert.
• git push wird in ein Remote-Repository verschoben, sodass ich es problemlos wiederherstellen kann, falls es jemals beschädigt wird.
• Ich hatte Aliase in erstellen C:\Usersmit , mklink /D link targetda einige Bibliotheken zu absoluten Positionen hingewiesen wurden.

Ich mag die am besten gewählte Antwort von Dan McNevin. Am Ende habe ich die Sequenz der Git-Befehle zu oft ausgeführt und beschlossen, 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 generiert ein Git-Repository ~/Dropbox/git/unter dem angegebenen Namen und überträgt den gesamten Inhalt des aktuellen Verzeichnisses in den neu erstellten Ursprungs-Master-Zweig. 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 Ursprungsmaster gesendet wird. Der Speicherort des Projektursprungsmasters kann auch mit dem Argument -m angegeben werden. Eine Standard-Gitignore-Datei wird ebenfalls im Remote-Zweigverzeichnis abgelegt. Die Standardeinstellungen für das Verzeichnis und die Gitignore-Datei werden im Skript angegeben.

Ein anderer Ansatz:

Alle bisherigen Antworten, einschließlich der beliebtesten @ Dan-Antwort , 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 die effektive Verwendung von "Git und Dropbox zusammen" wirklich bedeutet, arbeiten wir an einem anderen Ansatz: "Verwenden von Dropbox zum Synchronisieren nur des Arbeitsbaums".

Das How-to hat folgende Schritte:

1. innerhalb des Projektverzeichnis erstellt man ein leeres .gitVerzeichnis (zB mkdir -p myproject/.git)

2. Heben Sie die Synchronisierung des .gitVerzeichnisses in Dropbox auf. Wenn Sie die Dropbox-App verwenden: Gehen Sie zu Einstellungen, Synchronisieren und wählen Sie "Zu synchronisierende Ordner auswählen", wo das .gitVerzeichnis nicht markiert werden muss. Dadurch wird das .gitVerzeichnis entfernt.

3. git initim Projektverzeichnis ausführen

Es funktioniert auch, wenn das .gitbereits vorhanden ist. Führen Sie dann nur Schritt 2 aus. Dropbox behält jedoch eine Kopie der Git-Dateien auf der Website.

Schritt 2 führt dazu, 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 gepushen Änderungen haben eine Dropbox-Sicherung und werden geräteübergreifend synchronisiert.

• Für den Fall, dass Dropbox beim Synchronisieren zwischen Geräten etwas vermasselt git statusund git diffpraktisch ist, um die Dinge zu klären.

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

• Es vermeidet die Bedenken von @dubek und @Ates in den Kommentaren zu @ Dans Antwort und die Bedenken von @clu in einer anderen Antwort .

Die Existenz 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 potenzielles Problem besteht darin, dass Dropbox (unnötig?) Potenziell viele Dateien synchronisiert, wenn verschiedene Zweige ausgecheckt werden.

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

Eine Möglichkeit, diese Probleme zu umgehen git worktree, besteht darin, Zweigstellen-Checkouts in separaten Verzeichnissen zu speichern.

Für meine 2 Cent macht Dropbox nur Sinn für den persönlichen Gebrauch, wenn Sie sich nicht die Mühe machen möchten, einen zentralen Repo-Host zu bekommen. Für jede berufliche Entwicklung werden Sie wahrscheinlich mehr Probleme verursachen als lösen, wie bereits mehrfach im Thread erwähnt. Dropbox ist nicht für diesen Anwendungsfall konzipiert. Eine absolut sichere Methode zum Speichern von Repositorys auf Dropbox ohne Plugins oder Tools von Drittanbietern ist die Verwendung von Bundles. 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

Ich hatte ein ähnliches Problem und habe ein kleines Skript dafür erstellt. Die Idee ist, Dropbox mit Git so einfach wie möglich zu verwenden. Derzeit habe ich Ruby- Code schnell implementiert und werde bald weitere hinzufügen.

Das Skript ist unter zugänglich https://github.com/nuttylabs/box-git.

Ohne 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 Dateimodifikationen zu vermeiden, da ein Teilstatus hochgeladen und dann wieder heruntergeladen werden kann, wodurch Ihr Git-Status vollständig beschädigt wird.

Um dieses Problem zu vermeiden, habe ich:

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 Teilzustand mitten in 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 Notizen-Apps).

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

Unter MacOS können Sie Dropbox auch einfach stoppen, Ihre Änderungen vornehmen und Dropbox neu starten. Ich benutze die folgende Kombination und bin sehr zufrieden damit:

Führen Sie in beiden Fällen (Ihrem lokalen git-verwalteten Projektverzeichnis und Ihrem Remote-git-Repository in Dropbox) den folgenden Befehl aus, um das automatische Packen zu deaktivieren (was das Hauptproblem bei der Dropbox-Synchronisierung ist).

git config --global gc.auto 0

Komprimieren Sie dann von Zeit zu Zeit die Repositorys mit deaktivierter Dropbox. Zum Beispiel mache ich in meinem Bash-Build-Skript Folgendes, wenn ich neue Versionen meiner Apps erstelle.

osascript -e "tell application \"Dropbox\" to quit"

# Compress local
git gc --prune=now; git repack -a -d

# Compress remote
REPOS_DIR_REMOTE=`git remote get-url --push origin`
cd "${REPOS_DIR_REMOTE}"
git gc --prune=now; git repack -a -d

osascript -e "tell application \"Dropbox\" to launch"
osascript -e "display notification with title \"Compress Done\""