Usando Git e Dropbox insieme in modo efficace?

Come uso efficacemente Git e Dropbox insieme?

Penso che Git su Dropbox sia fantastico. Lo uso sempre. Ho più computer (due a casa e uno al lavoro) che uso Dropbox come repository centrale nudo. Dato che non voglio ospitarlo su un servizio pubblico e non ho accesso a un server a cui posso sempre accedere, Dropbox si occupa di questo sincronizzando (molto rapidamente) in background.

L'installazione è simile a questa:

~/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

Da lì, puoi semplicemente clonare ~/Dropbox/git/project.gitche hai associato al tuo account Dropbox (o aver condiviso questa directory con le persone), puoi fare tutte le normali operazioni di Git e verranno sincronizzate automaticamente con tutte le altre macchine.

Ho scritto un post sul blog, Il controllo della versione , ( vecchio link ^morti ) sul mio ragionamento e di come ho creato il mio ambiente, si basa sul mio Ruby on Rails esperienza di sviluppo, ma può essere applicato a qualsiasi cosa, davvero.

Il modo giusto per farlo è usare git-remote-dropbox: https://github.com/anishathalye/git-remote-dropbox

La creazione del proprio repository nudo in Dropbox causa molti problemi. Anish (il creatore della biblioteca) lo spiega meglio :

La causa principale di questi problemi è che il client desktop Dropbox è progettato per sincronizzare i file, non i repository Git. Senza una gestione speciale per i repository Git, non mantiene le stesse garanzie di Git. Le operazioni sul repository remoto non sono più atomiche e operazioni simultanee o tempi sfortunati con la sincronizzazione possono causare un repository danneggiato.

I telecomandi Git tradizionali eseguono il codice sul lato server per farlo funzionare correttamente, ma non possiamo farlo.

Soluzione: è possibile risolverlo correttamente. È possibile utilizzare Git con Dropbox e avere le stesse garanzie di sicurezza e coerenza di un telecomando Git tradizionale, anche quando ci sono più utenti e operazioni simultanee!

Per un utente, è semplice come usare git-remote-dropbox, un supporto remoto Git che funge da ponte bidirezionale trasparente tra Git e Dropbox e mantiene tutte le garanzie di un telecomando Git tradizionale. È anche sicuro da usare con le cartelle condivise, quindi può essere utilizzato per la collaborazione (yay repository privati ​​illimitati con collaboratori illimitati!).

Con l'helper remoto, è possibile utilizzare Dropbox come telecomando Git e continuare a utilizzare tutti i normali comandi Git come git clone, git pull e git push, e tutto funzionerà come previsto.

Questa risposta si basa sull'esperienza di Mercurial , non su Git, ma questa esperienza afferma che l'utilizzo di Dropbox in questo modo richiede repository corrotti se esiste la possibilità che aggiornerai lo stesso repository basato su Dropbox da macchine diverse in diversi momenti (Mac, Unix, Windows nel mio caso).

Non ho un elenco completo delle cose che possono andare storte, ma ecco un esempio specifico che mi ha morso. Ogni macchina ha la propria nozione di caratteri di fine riga e di come i caratteri maiuscoli / minuscoli vengono gestiti nei nomi dei file. Dropbox e Git / Mercurial gestiscono questo in modo leggermente diverso (non ricordo le differenze esatte). Se Dropbox aggiorna il repository dietro il repository Git / Mercurial, presto, repository rotto. Questo accade immediatamente e invisibilmente, quindi non sai nemmeno che il tuo repository è rotto fino a quando non provi a recuperarne qualcosa.

Dopo essere uscito da un pasticcio facendo le cose in questo modo, ho usato la seguente ricetta con grande successo e nessun segno di problemi. Basta spostare il repository da Dropbox. Usa Dropbox per tutto il resto; documentazione, file JAR , qualsiasi cosa tu voglia. E usa GitHub (Git) o Bitbucket (Mercurial) per gestire il repository stesso. Entrambi sono gratuiti, quindi questo non aggiunge nulla ai costi e ogni strumento ora gioca ai suoi punti di forza.

L'esecuzione di Git / Mercurial sopra Dropbox non aggiunge altro che rischi. Non farlo

Per quanto riguarda i piccoli team che utilizzano Dropbox:

Se ogni sviluppatore ha il proprio repository nudo scrivibile su Dropbox, che è disponibile solo per altri sviluppatori, ciò facilita la condivisione del codice senza rischio di corruzione!

Quindi, se si desidera una "linea principale" centralizzata, è possibile avere uno sviluppatore a gestire tutte le spinte ad esso dal proprio repository.

Non volevo mettere tutti i miei progetti in un repository Git, né volevo entrare ed eseguire questo codice per ogni singolo progetto, quindi ho creato uno script Bash che automatizzerà il processo. Puoi usarlo su una o più directory, così può fare il codice in questo post per te o può farlo su più progetti contemporaneamente.

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

Non penso che usare Git e Dropbox sia la strada da percorrere ... Basti pensare alle funzionalità di entrambi:

Idiota:

• Ti permette di avere un repository centrale
• Ti consente di avere il tuo repository con le tue modifiche
• Consente di inviare e ricevere modifiche dal repository centrale
• Consente a più persone di modificare gli stessi file e li unisce o ti chiede di unirli se non è possibile farlo
• Dispone di client Web e desktop per consentire l'accesso al repository centrale

Dropbox:

• Mantiene tutto in un repository centrale
• Ti consente di avere le tue versioni dei file nel server
• Ti obbliga a inviare e ricevere modifiche dal repository centrale
• Se più persone cambiano gli stessi file, il primo file sottoposto a commit viene sostituito con commit successivi e non si verifica alcuna unione che sia problematica (e sicuramente il suo più grande svantaggio)
• Dispone di client Web e desktop per consentire l'accesso al repository centrale.

E se sei preoccupato di condividere alcuni dei tuoi file, perché non cifrarli? E poi potresti ottenere il più grande vantaggio di Dropbox su Git, ovvero avere file pubblici e privati ​​...

È ora il 2015 e già tre giorni fa è stato creato un nuovo strumento basato sull'API Dropbox v2 per utilizzare Git in sicurezza su Dropbox. Funziona con l'API anziché utilizzare il client desktop e gestisce correttamente più push simultanei su un repository ospitato in una cartella condivisa.

Una volta configurato, consente di configurare un telecomando git esattamente come qualsiasi altro telecomando git.

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

Uso Mercurial (o Git) + TrueCrypt + Dropbox per backup remoti crittografati .

La cosa più interessante è che Dropbox NON sincronizza l'intero contenitore TrueCrypt se si modifica una piccola parte del codice. Il tempo di sincronizzazione è approssimativamente proporzionale alla quantità di modifiche. Anche se è crittografato, la combinazione di TrueCrypt + Dropbox fa un uso eccellente della crittografia a blocchi + sincronizzazione a livello di blocco.

In secondo luogo, un contenitore crittografato monolitico non solo aggiunge sicurezza, ma riduce anche le possibilità di corruzione del repository .

Attenzione: tuttavia, è necessario fare molta attenzione a non montare il contenitore mentre Dropbox è in esecuzione. Può anche essere una seccatura risolvere i conflitti se 2 client diversi effettuano il check-in versioni diverse nel contenitore. Quindi, è pratico solo per una singola persona che lo utilizza per i backup, non per un team.

Impostare:

• Crea un contenitore Truecrypt (va bene più Gigabyte)
• In Preferenze TrueCrypt, deseleziona preserve modification timestamp*.
• Crea un repository come menzionato sopra da Dan ( https://stackoverflow.com/a/1961515/781695 )

Uso:

• Esci da Dropbox
• Montare il contenitore, spingere le modifiche, smontare
• Esegui dropbox

PS Deselezionando la casella di controllo preserve modification timestampindica che il file è stato modificato e deve essere sincronizzato. Si noti che il montaggio del contenitore modifica il timestamp anche se non si modifica alcun file al suo interno. Se non vuoi che ciò accada, monta semplicemente il volume comeread-only

Adoro la risposta di Dan McNevin! Sto usando anche Git e Dropbox insieme ora e sto usando diversi alias nel mio .bash_profile, quindi il mio flusso di lavoro è simile al seguente:

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

Questi sono i miei alias:

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'

Usiamo questo metodo (creando un repository nudo in Dropbox) su una cartella condivisa .

Un piccolo gruppo di sviluppatori può estrarre da quel repository sincronizzato e creare un clone locale. Una volta terminata l'unità di lavoro, torniamo all'origine.

Una cosa che mi manca è un buon modo per ricevere un'e-mail con le informazioni sul set di modifiche una volta che si verifica un push all'origine. Stiamo utilizzando Google Wave per tenere traccia manualmente delle modifiche.

Ho usato Mercurial nel modo raccomandato e chiedo che tu sia cauto, specialmente se una delle macchine differisce. I forum di Dropbox sono pieni di lamentele per i misteriosi casi di nomi di file che si presentano spontaneamente. Hg (e presumo che Git) non noterà né si lamenterà durante i check-in di routine e sentirai parlare della corruzione solo quando si lamenta di un repository corrotto quando provi ad usarlo davvero. Cattive notizie. Vorrei poter essere più specifico sul problema e le sue soluzioni alternative; Sto ancora cercando di scavare da questo casino da solo.

Esiste anche un progetto open source (una raccolta di script multipiattaforma [Linux, Mac, Win]) che esegue tutti i dettagli chiacchieroni della gestione del repository con una manciata (3-4) di comandi.

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

L'uso del campione è:

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

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

Dopo di che normale utilizzo di git:

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

Controlla la wiki del progetto e i manuali per i riferimenti completi ai comandi e le esercitazioni.

Conservo i miei repo non Github su Dropbox. Un avvertimento che ho riscontrato è stato la sincronizzazione dopo una reinstallazione. Dropbox scaricherà i file più piccoli prima di passare a quelli più grandi. Non è un problema se inizi di notte e torni dopo il fine settimana :-)

La mia discussione - http://forums.dropbox.com/topic.php?id=29984&replies=6

Nel 2014 uso Git e Dropbox da circa un anno e mezzo senza problemi. Alcuni punti però:

• Tutte le mie macchine che usano Dropbox sono su Windows, diverse versioni (da 7 a 8) + 1 mac.
• Non condivido il repository con qualcun altro, quindi sono l'unico a modificarlo.
• git push spinge in un repository remoto, in modo che se viene danneggiato, posso facilmente recuperarlo.
• Ho dovuto creare alias in C:\Userscon mklink /D link targetquanto alcune librerie erano puntate a posizioni assolute.

Mi piace la risposta più votata da Dan McNevin. Ho finito per eseguire la sequenza di comandi git troppe volte e ho deciso di creare uno script. Quindi eccolo qui:

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

Lo script richiede solo un nome di progetto. Genererà un repository git ~/Dropbox/git/con il nome specificato e invierà l'intero contenuto della directory corrente al ramo master di origine appena creato. Se viene fornito più di un nome progetto, verrà utilizzato l'argomento nome progetto più a destra.

Facoltativamente, l'argomento del comando -r specifica il ramo remoto che invierà al master di origine. La posizione del master di origine del progetto può anche essere specificata con l'argomento -m. Un file .gitignore predefinito viene inoltre inserito nella directory della diramazione remota. Le impostazioni predefinite della directory e del file .gitignore sono specificate nello script.

Un altro approccio:

Tutte le risposte finora, inclusa la risposta @Dan che è la più popolare, affrontano l'idea di utilizzare Dropbox per centralizzare un repository condiviso invece di utilizzare un servizio incentrato su git come github, bitbucket, ecc.

Ma, poiché la domanda originale non specifica cosa significhi realmente usare "Git e Dropbox insieme", lavoriamo su un altro approccio: "Usare Dropbox per sincronizzare solo il worktree".

Il tutorial ha questi passaggi:

1. all'interno della directory del progetto, si crea una .gitdirectory vuota (ad es. mkdir -p myproject/.git)

2. annulla la sincronizzazione della .gitdirectory in Dropbox. Se usi l'app Dropbox: vai su Preferenze, Sincronizza e "scegli cartelle da sincronizzare", dove la .gitdirectory deve essere deselezionata. Questo rimuoverà la .gitdirectory.

3. eseguito git initnella directory del progetto

Funziona anche se .gitesiste già, quindi esegui solo il passaggio 2. Dropbox manterrà comunque una copia dei file git nel sito Web.

Il passaggio 2 farà in modo che Dropbox non sincronizzi la struttura del sistema git, che è il risultato desiderato per questo approccio.

Perché uno dovrebbe usare questo approccio?

• Le modifiche non ancora inviate avranno un backup Dropbox e verrebbero sincronizzate su tutti i dispositivi.

• Nel caso Dropbox rovini qualcosa durante la sincronizzazione tra i dispositivi git statuse git diffsarà utile per risolvere le cose.

• Risparmia spazio nell'account Dropbox (l'intera cronologia non verrà memorizzata lì)

• Evita le preoccupazioni sollevate da @dubek e @Ates nei commenti sulla risposta di @ Dan e le preoccupazioni di @clu in un'altra risposta .

L'esistenza di un remoto altrove (github, ecc.) Funzionerà bene con questo approccio.

Lavorare su diversi rami porta alcuni problemi, che devono essere curati:

• Un potenziale problema è che Dropbox (inutilmente?) Sincronizzi potenzialmente molti file quando si verificano diversi rami.

• Se due o più dispositivi sincronizzati Dropbox hanno check out diversi, è possibile perdere le modifiche non impegnate su entrambi i dispositivi,

Un modo per aggirare questi problemi è utilizzare git worktreeper mantenere i checkout delle filiali in directory separate.

Per i miei 2 centesimi Dropbox ha senso solo per uso personale in cui non si desidera preoccuparsi di ottenere un host repo centrale. Per qualsiasi sviluppo professionale probabilmente creerai più problemi di quanti ne risolverai, come già menzionato più volte nel thread, Dropbox non è progettato per questo caso d'uso. Detto questo, un metodo perfettamente sicuro per scaricare i repository su Dropbox senza plug-in o strumenti di terze parti è utilizzare i bundle. Ho i seguenti alias nel mio .gitconfigper salvare la digitazione:

[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 #"

Esempio:

# 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

Ho affrontato un problema simile e ho creato un piccolo script per lo stesso. L'idea è di utilizzare Dropbox con Git nel modo più semplice possibile. Attualmente, ho implementato rapidamente Ruby codice e presto ne aggiungerò altri.

Lo script è accessibile all'indirizzo https://github.com/nuttylabs/box-git.

Senza utilizzare strumenti di integrazione di terze parti, potrei migliorare un po 'la condizione e utilizzare DropBox e altri servizi simili su disco cloud come SpiderOak con Git.

L'obiettivo è evitare la sincronizzazione nel mezzo di queste modifiche ai file, in quanto può caricare uno stato parziale e poi lo scaricherà nuovamente, corrompendo completamente il tuo stato git.

Per evitare questo problema, ho fatto:

1. Raggruppa il mio indice git in un file usando git bundle create my_repo.git --all.
2. Impostare un ritardo per il monitoraggio del file, ad es. 5 minuti, anziché istantaneo. Ciò riduce le possibilità che DropBox sincronizzi uno stato parziale nel mezzo di una modifica. Aiuta anche molto quando si modificano i file sul disco cloud al volo (come con le app per prendere appunti con salvataggio istantaneo).

Non è perfetto in quanto non vi è alcuna garanzia che non rovinerà di nuovo lo stato git, ma aiuta e per il momento non ho riscontrato alcun problema.

Su MacOS puoi anche interrompere Dropbox, apportare le modifiche e riavviare Dropbox. Sto usando la seguente combinazione e ne sono abbastanza contento:

In entrambi (la directory del progetto gestito da git locale e il repository git remoto situato su Dropbox), eseguire il comando seguente per disabilitare l'auto-imballaggio (che è il problema principale con la sincronizzazione di dropbox)

git config --global gc.auto 0

Di tanto in tanto, comprimere i repository con dropbox disabilitato. Ad esempio, faccio quanto segue nel mio script bash-build ogni volta che realizzo nuove versioni delle mie app.

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