Git und Dropbox effektiv zusammen nutzen?

1132

Wie nutze ich Git und Dropbox effektiv zusammen?

n1kh1lp
quelle
2
Siehe auch Bradley Wrights Tutorial .
Ron Romero
39
Wenn Sie nur ein kleines Team sind (bis zu 5, glaube ich), bietet BitBucket kostenloses Hosting für private Repositories. Ironischerweise habe ich dann mein lokales Repo auf DropBox, nur für den Fall, dass ich zwischen Computern wechsle, wenn ich an etwas arbeite.
Mark Adamson
12
Ich bin nicht sicher, ob Ihre Versionsredundanz ironisch ist, aber es ist wahrscheinlich sehr nützlich
silasdavis
2
Diese Frage ist unklar. Was bedeutet es, diese Tools "effektiv" zusammen zu nutzen? Es ist auch zu weit gefasst und kann zu Meinungsäußerungen führen.
3
Hey, könnten Sie bitte meine Antwort als die richtige betrachten: stackoverflow.com/a/32215708/589667 . Diese Bibliothek, die ich in meiner Antwort erwähne, ist ein offizielles Tool, das von Dropbox-Entwicklern entwickelt wurde, um Menschen bei der Verwendung von Git mit Dropbox zu helfen.
Clu

Antworten:

1401

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.

Dan McNevin
quelle
61
Ich frage mich, was passiert, wenn Sie von zwei Maschinen gleichzeitig auf das Dropbox-Bare-Repo zugreifen. Wenn es zu einer Änderung in einer der internen Dateien von git kommt, zeigt Dropbox an, dass ein Konflikt vorliegt - aber was machen Sie dann? Wählen Sie einfach eine der Versionen aus und drücken Sie dann erneut von beiden Maschinen (eine nach der anderen)?
Dubek
162
@dubek: Sie werden wahrscheinlich das gemeinsam genutzte Bare Repo beschädigen. Dieser Ansatz ist nur für ein kleines Team geeignet (in meinem Fall zwei), in dem die Leute einfach über ihre Kabinenwände schreien können: "Hey! Niemand drückt! Ich drücke jetzt!".
Ates Goral
50
@Ates: Zumindest git ist dezentralisiert. Wenn Sie es also schaffen, Dinge zu beschädigen, können Sie es von einer lokalen Kopie einer anderen Person wiederherstellen. Wenn Sie ein großes Team haben, besteht die Möglichkeit, dass irgendwo genug Geld für ein gehostetes Repo vorhanden ist.
Rdrey
75
Ich bin mehr als fünf Mal auf diese Seite zurückgekehrt, um genau diese Befehlsfolge zu verwenden. Ich werde sie nie auswendig lernen, aber danke, dass du sie zur Verfügung gestellt hast!
Jeremy Mack
32
@ Jo: Es ist nicht Ghetto genug.
Ates Goral
126

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.

clu
quelle
8
Ich bin froh zu sehen, dass jemand über git-remote-dropbox in dieser StackOverflow-Frage geschrieben hat. Ich frage mich, ob es eine Möglichkeit gibt, diese Antwort näher an die Spitze zu bringen. Die von der aktuell akzeptierten Antwort empfohlene Methode ist ziemlich gefährlich und kann zu einer Beschädigung des Repositorys führen.
fwenom
1
das ist echt cool. Ich werde es auf jeden Fall überprüfen. Aber wenn ich von einer Entwicklungsbox zur nächsten wechsle und weiter an einem synchronisierten Repo arbeiten möchte, funktioniert diese Methode nur, wenn ich meine Arbeit immer festschreibe, wenn ich Maschine A verlasse und dort weitermachen möchte, wo ich aufgehört habe Maschine B. habe ich recht? Wenn ja, ist dies nicht ideal, da dies zu einer Flut von "vorläufigen" Commits führen würde, von denen man behaupten könnte, dass sie die Commit-Geschichte des Repos verschmutzen. Vielleicht kann ich meinen Kuchen einfach nicht haben und ihn auch essen!
Bhu Boue Vidya
@bhuBouevidya Nein, das stimmt nicht. Sie müssen Ihre Arbeit nicht festlegen, damit die Änderungen synchronisiert werden. Solange die Dateien gespeichert sind, werden sie synchronisiert. Wenn Sie eine Reihe geänderter Dateien auf einem Computer haben, werden die Änderungen grundsätzlich mit dem anderen synchronisiert, da Dropbox sich nur darum kümmert, was auf der Festplatte gespeichert wurde.
Clu
2
@clu: Ja, du musst deine Arbeit verpflichten und pushen. Alles, was git-remote-dropbox tut, ist als git remote helper zu fungieren. Genau wie bei anderen Fernbedienungen werden Ihre lokalen Commits erst dann auf die Fernbedienung übertragen, wenn ein Push ausgeführt wurde. Die Möglichkeit, lokal geänderte Dateien in das lokale Repository zu übertragen, damit sie übertragen werden können, besteht in einem Commit. Dropbox weiß nichts über Ihre Dateien, die sich nicht im Repository befinden.
Ameisen
2
Nur neugierig, ob git-remote-dropbox plattformübergreifend ist ... Ich sehe, dass Python verwendet wird, und ich weiß, dass bestimmte andere Python-Inhalte für Dropbox nicht plattformübergreifend sind. Beispielsweise ist das Befehlszeilenmaterial unter OS X nicht kompatibel.
Michael
89

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.

Bradjcox
quelle
13
Ich bin der Meinung, dass das Git-Repository robust genug ist, um sich nicht selbst zu beschädigen. Meine Erfahrung (über ein Jahr Nutzung, hauptsächlich Einzelbenutzer, plattformübergreifende, computerübergreifende, mehrere Entwickler) ist, dass das Repo von git nicht leicht beschädigt werden kann. In git werden nur Informationen zum Repository hinzugefügt, vorhandene Dateien bleiben in 99,9% der Fälle allein (veränderbare Dateien lassen sich meist leicht manuell überprüfen). Ich habe manchmal Fälle gesehen, in denen ein Verzweigungszeiger überschrieben wurde, aber dies kann leicht gesehen (dh "Verzweigung (XXXs widersprüchliche Kopie)") und entfernt werden (eigentlich ist keine echte Korrektur erforderlich).
Egon
1
@tc: Sie haben Recht, während der Speicherbereinigung werden nicht erreichbare Informationen in Git entfernt. Ich denke jedoch, dass dies in den meisten praktischen Fällen die Robustheit nicht beeinträchtigt: Es sind nur nicht erreichbare Informationen betroffen, die älter als 2 Wochen sind (was ausreichend Zeit für die Synchronisierung von DropBox ist). Und in diesem Moment eines solchen Konflikts vermute ich, dass die meisten Informationen sowohl in verpackter als auch in unverpackter Form verfügbar sein werden.
Egon
Ich denke, dass das Code-Sharing-Szenario ohne zentrales Repo (in einer Antwort unten beschrieben) einen vor möglichen Beschädigungen aufgrund gleichzeitiger Aktualisierungen des Verzeichnisses in der Dropbox bewahren würde. Wenn ein zentrales Repo benötigt wird, kann es separat verwaltet werden (und außerhalb der Dropbox liegen). In der Dropbox befinden sich persönliche Arbeits-Repos (was auch praktisch ist, da Sie von Zeit zu Zeit das Quell-Repo eines anderen in Ihrem Team, auf dem Sie arbeiten, aktualisieren / abrufen können). (Ich denke tatsächlich darüber nach, Darcs in einer solchen Umgebung
einzusetzen
5
+1 Wenn Sie Ihre Repositorys nicht öffentlich hosten möchten, verwenden Sie Bitbucket . Private Repos sind für Teams mit bis zu 5 Benutzern kostenlos.
Christian Specht
Eine Sache, die ich zwischen einem Windows-Computer und einem OSX-Computer bemerkt habe, ist, dass Dateiberechtigungen verschiedene Probleme verursachen können. Sie können Berechtigungen in Git deaktivieren, indem Sie Folgendes verwenden: "git config core.fileMode false"
devdrc
16

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.

teh_senaus
quelle
1
So toll! Um die Repo-Beschädigung vor mehreren Schreibvorgängen zu schützen, können Sie problemlos MEHRERE Repos erstellen und nur deren .git-Ordner synchronisieren! Alles was Sie in einem Moment brauchen - ist vom gewünschten Ursprung zu ziehen! Großartiger P-to-P-Mann! Sie verstehen die Philosophie des dezentralen Git!
Brian Haak
16

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
Eli
quelle
15

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 ...

Coyote21
quelle
Dropbox ist nur eine gute Option für ein zentrales Repo. Wenn es in einem freigegebenen Ordner abgelegt wird, funktioniert es sogar für Gruppen.
Mac
Ja, aber Sie haben nicht die gleichen Zusammenführungsfunktionen wie in git. Wenn jemand dieselbe Datei wie Ihre bearbeitet und die Datei nach Ihnen speichert, gehen Ihre Änderungen verloren, es sei denn, Sie gehen zur Weboberfläche und laden sie herunter die alte Version (Ihre Version).
Coyote21
8
Das ist falsch. Dropbox lässt keine Konflikte fallen. Es entstellt den Dateinamen einer Bearbeitung und verwendet den anderen für die Kontinuität. Sie können sie manuell selbst zusammenführen, wenn Sie möchten. Es ist ein guter Kompromiss und verliert keine Daten. dropbox.com/help/36
Ahnungslos
5
Ja, aber da es sich um Code handelt, kann ich umso mehr Code produzieren, je weniger Zeit ich mit dem Zusammenführen von Dateien verbringe. In einer normalen Codebasis können je nach Projektdimension Hunderte von Konflikten gleichzeitig auftreten, und dies wäre ein Albtraum dann nacheinander zusammenführen, auch mit Hilfe eines Zusammenführungstools wie WinMerge (oder ähnlichem).
Coyote21
15

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"
merlin2011
quelle
2
Es wäre schön, wenn ein Mod all die vielen Git-with-Dropbox-Fragen zum Stackexchange unter einem Superthread zusammenführen würde, in dem die neuesten Dinge zuerst erwähnt werden.
Blair Houghton
9

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

Benutzer
quelle
Wäre es viel anders, wenn Sie ein mit MacOS verschlüsseltes .dmg-Dateibild verwenden würden, wäre die Synchronisierungszeit immer noch ungefähr proportional zu den Änderungen?
IBrum
@IBrum Sorry, ich habe es nicht mit einer .dmg-Datei versucht
Benutzer
7

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'
Michiel de Mare
quelle
Ich würde das Letzte wahrscheinlich nicht als Alias ​​verwenden, sondern als Shell-Skript. Ansonsten gefällt mir das sehr gut. Extra Gutschrift für awk Nutzung.
Pauljohn32
6

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.

dengel
quelle
81
Jemand benutzt Google Wave?
Kristopher Johnson
6

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.

Brad Cox
quelle
Ich hatte das gleiche Problem mit Quecksilber
Tomba
Git prüft viel häufiger auf Beschädigungen als andere. Zumindest wissen Sie, wann dies geschieht, und können das Problem beheben.
Anders
6

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.

Péter Szilágyi
quelle
4

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

Ben
quelle
4

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.
Mikaël Mayer
quelle
3

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.

ChisholmKyle
quelle
3

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.

IBrum
quelle
Als jemand, der an Dateien arbeitet, die eine Versionskontrolle ermöglichen, aber auch auf einem iPad (über Dropbox-Synchronisierung) bearbeitet werden können, deckt diese Antwort diesen Anwendungsfall ab.
Vagari
Schnelle Nachverfolgung, das aktuelle Dropbox-Verhalten ist anders. Das einfache Entfernen und Anweisen von Dropbox, nicht zu synchronisieren, bedeutet das Gegenteil, bleibt in der Cloud und wird aus der lokalen entfernt. Aber es gibt eine Superuser-Antwort mit einer Lösung. superuser.com/a/1527145/109561 In meinem Fall (auf einem Mac) kennzeichnet das Folgende die Datei zum Ignorieren xattr -w com.dropbox.ignored 1 /path/to/somewhere.
Vagari
3

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
Niklas Holm
quelle
2

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.

Kiran Madipally
quelle
0

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.

gaborous
quelle
0

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\""
berbie
quelle