Utiliser Git et Dropbox ensemble efficacement?

la bonne façon de procéder est d'utiliser git-remote-dropbox: https://github.com/anishathalye/git-remote-dropbox

la création de votre propre repo nu dans Dropbox provoque beaucoup de problèmes. Anish (le créateur de la bibliothèque) l'explique le mieux :

la cause fondamentale de ces problèmes est que le bureau Dropbox le client est conçu pour synchroniser des fichiers, pas des dépôts Git. Sans spécial gestion pour les dépôts Git, il ne maintient pas le même garanties comme Git. Les opérations sur le dépôt distant ne sont plus opérations atomiques, et simultanées ou mauvais timing avec la synchronisation peut aboutir à un dépôt corrompu.

remotes Git traditionnels exécuter le code du côté du serveur pour faire ce travail correctement, mais on ne peut pas faire ça.

Solution: il est possible de résoudre ce problème correctement. Il est possible d'utiliser Git avec Dropbox et ont les mêmes garanties de sécurité et de consistance comme une télécommande Git traditionnelle, même lorsqu'Il ya plusieurs utilisateurs et opérations simultanées!

pour un utilisateur, c'est aussi simple que d'utiliser git-remote-dropbox, un git remote aide qui agit comme un pont bidirectionnel transparent entre Git et Dropbox et maintient toutes les garanties d'une télécommande Git traditionnelle. C'est même sûr à utiliser avec les dossiers partagés, de sorte qu'il peut être utilisé pour la collaboration (yay illimitée prises en pension privées illimitées les collaborateurs!).

avec l'aide à distance, il est possible D'utiliser Dropbox comme une télécommande Git et continuer à utiliser toutes les commandes git régulières comme git clone, git tirer, et git push, et tout fonctionnera comme prévu.

cette réponse est basée sur Mercurial expérience, pas Git, mais cette expérience dit que L'utilisation de Dropbox de cette façon demande des dépôts corrompus s'il y a même une chance que vous mettiez à jour le même dépôt Dropbox basé sur différentes machines à des moments différents (Mac, Unix, Windows dans mon cas).

je n'ai pas une liste complète des choses qui peuvent mal se passer, mais voici un exemple qui m'a mordu. Chaque machine a sa propre idée des caractères de fin de ligne et comment les caractères majuscules/minuscules sont traités dans les noms de fichier. Dropbox et Git / Mercurial gèrent cela un peu différemment (Je ne me souviens pas des différences exactes). Si Dropbox met à jour le dépôt derrière le dos de Git/Mercurial, presto, le dépôt cassé. Cela se produit immédiatement et de façon invisible, de sorte que vous ne savez même pas que votre dépôt est brisé tant que vous n'avez pas essayé de récupérer quelque chose.

après être sorti d'une pagaille en faisant les choses de cette façon, j'ai j'ai utilisé la recette suivante avec beaucoup de succès et aucun signe de problèmes. Il suffit de déplacer votre dépôt hors de Dropbox. Utilisez Dropbox pour tout le reste; documentation, fichiers JAR , tout ce que vous voulez. Et utilisez Github (Git) ou Bitbucket (Mercurial) pour gérer le dépôt lui-même. Les deux sont GRATUITS donc cela n'ajoute rien aux coûts, et chaque outil joue maintenant à ses forces.

Running Git / Mercurial en haut de Dropbox n'ajoute rien à part le risque. Ne pas le faire.

en ce qui concerne les petites équipes utilisant Dropbox:

si chaque développeur dispose de son propre dépôt vierge sur Dropbox, qui est pull only pour les autres développeurs, alors cela facilite le partage de code sans risque de corruption!

alors si vous voulez une "ligne principale" centralisée, vous pouvez avoir un développeur gérer tous les pushs à elle de leur propre repo.

Je ne voulais pas mettre tous mes projets sous un seul dépôt Git, ni entrer et exécuter ce code pour chaque projet, donc j'ai fait un script Bash qui va automatiser le processus. Vous pouvez l'utiliser sur un ou plusieurs répertoires -, donc il peut faire le code dans ce post pour vous ou il peut le faire sur plusieurs projets à la fois.

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

Je ne pense pas qu'utiliser Git et Dropbox soit la solution... Il suffit de penser aux caractéristiques des deux:

Git:

• vous permet d'avoir un dépôt central
• vous permet d'avoir votre propre dépôt avec vos propres modifications
• vous permet d'envoyer et de recevoir des modifications depuis le dépôt central
• permet à plusieurs personnes de changer les mêmes fichiers et les fusionne ou vous demande de fusion, si elle ne peut pas le faire
• a des clients Web et de bureau pour permettre l'accès au dépôt central

Dropbox:

• garde tout dans un dépôt central
• vous permet d'avoir vos propres versions des fichiers dans le serveur
• vous oblige à envoyer et à recevoir des modifications depuis le dépôt central
• si multiple les personnes changent les mêmes fichiers, le premier fichier engagé est remplacé par des propagations ultérieures, et aucune fusion ne se produit ce qui est gênant (et certainement son plus grand inconvénient)
• a des clients Web et de bureau pour permettre l'accès au dépôt central.

et si vous êtes inquiet de partager certains de vos fichiers, pourquoi ne pas les crypter? Et puis vous pourriez obtenir le plus grand avantage de Dropbox à Git, c'est-à-dire, d'avoir des fichiers publics et privés...

nous sommes en 2015, et depuis trois jours, un nouvel outil basé sur Dropbox API v2 a été créé pour utiliser en toute sécurité Git sur Dropbox. Il fonctionne contre L'API plutôt que d'utiliser le client desktop, et gère correctement plusieurs pushs simultanés vers un dépôt hébergé dans un dossier partagé.

une fois configuré, il permet de configurer une télécommande git exactement comme n'importe quelle autre télécommande git.

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

j'utilise Mercurial (ou Git) + TrueCrypt + Dropbox pour crypté à distance sauvegardes .

la chose la plus cool est que Dropbox ne synchronise pas le conteneur TrueCrypt entier si vous modifiez une petite partie de votre code. Le temps de synchronisation est à peu près proportionnel à la quantité de changements. Même s'il est crypté, la combinaison de TrueCrypt + Dropbox fait un excellent usage de block cipher + block level sync.

deuxièmement, un conteneur crypté monolithique non seulement ajoute de la sécurité, il réduit également les chances de dépôt corruption .

attention: cependant vous devez faire très attention à ne pas avoir le conteneur monté pendant que Dropbox est en cours d'exécution. Il peut également être difficile de résoudre les conflits si deux clients différents check-in différentes versions du conteneur. Donc, c'est pratique seulement pour une seule personne l'utilisant pour les sauvegardes, et non pas pour une équipe.

Installation:

• création d'un conteneur Truecrypt (plusieurs Gigabyte est très bien)
• Sous Truecrypt préférences, décochez la case preserve modification timestamp *.
• créer un repo comme mentionné ci-dessus par Dan ( https://stackoverflow.com/a/1961515/781695 )

Utilisation:

• Quittez Dropbox
• montez le conteneur, poussez vos modifications ,démontez
• Exécuter dropbox

P.S. décochant le preserve modification timestamp indique à dropbox que le fichier a été modifié et qu'il doit être synchronisé. Notez que le montage du conteneur modifie l'horodatage même si vous n'y changez aucun fichier. Si vous ne voulez pas que cela se produise, montez simplement le volume comme read-only

J'ai utilisé Mercurial de la manière recommandée et j'insiste pour que vous soyez prudent, surtout si l'une des machines diffère. Les forums Dropbox sont remplis de plaintes de mystérieux problèmes de noms de fichiers apparaissant spontanément. Hg (et je présume que Git) ne remarquera pas ou ne se plaindra pas pendant les contrôles de routine et vous n'entendrez parler de la corruption quand il se plaint d'un repo corrompu quand vous essayez de l'utiliser pour de vrai. Les mauvaises nouvelles. J'aimerais être plus précis sur le problème et son solutions de contournement; je suis encore à essayer de creuser de ce gâchis moi-même.

j'adore la réponse de Dan McNevin! J'utilise Git et Dropbox ensemble aussi maintenant, et j'utilise plusieurs alias dans mon .bash_profile donc mon workflow ressemble à ceci:

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

ce sont mes pseudonymes:

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'

nous utilisons cette méthode (création d'un dépôt nu dans Dropbox) sur un dossier de partage .

un petit groupe de développeurs peut tirer de ce dépôt nu synchronisé et créer un clone local. Une fois l'Unité de travail terminée, nous revenons à l'origine.

une chose qui me manque, c'est une bonne façon de faire envoyer un e-mail avec les informations de changement une fois qu'une poussée vers l'origine se produit. Nous utilisons Google Wave pour suivre manuellement changement.

il y a aussi un projet open source (une collection de scripts multiplateformes [Linux, Mac, Win]) qui fait tous les détails de la gestion du dépôt avec une poignée (3-4) de commandes.

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

exemple d'utilisation:

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

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

après quoi l'usage normal de git:

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

Vérifier le wiki de projet et le manuels de référence de commande complète et tutoriels.

je stocke mon Non-GitHub repo sur Dropbox. Je suis tombé sur la synchronisation après une réinstallation. Dropbox téléchargera d'abord les plus petits fichiers avant de passer aux plus grands. Pas un problème si vous commencez à partir de la nuit et de revenir après le week-end :-)

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

j'aime le haut-voté réponse par Dan mcnevin création. J'ai fini par faire la séquence des commandes git trop souvent et j'ai décidé de faire un script. Alors voilà:

#!/bin/bash

# Usage
usage() {
    echo "Usage: "151900920" -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 "" in
        '-h' | '--help' ) usage ;;
        '-m' )
            shift
            masterdir=""
            ;;
        '-r' )
            shift
            remotedir=""
            ;;
        * )
            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}"

le script ne requiert qu'un nom de projet. Il générera un dépôt git dans ~/Dropbox/git/ sous le nom spécifié et poussera le contenu entier du répertoire courant vers la nouvelle branche principale origin. Si plus d'un nom de projet est donné, le plus à droite le nom du projet l'argument sera utilisé.

optionnellement, l'argument de Commande-r spécifie la branche distante qui poussera vers le maître d'origine. L'emplacement du maître d'origine du projet peut également être spécifié avec l'argument-M. Défaut. gitignore fichier est également placé dans la branche distante répertoire. L'annuaire et .les valeurs par défaut du fichier gitignore sont spécifiées dans le script.

en 2014, j'utilise Git et Dropbox depuis environ un an et demi sans problème. Quelques points cependant:

• toutes mes machines utilisant Dropbox sont sous Windows, différentes versions (7 à 8) + 1 mac.
• je ne partage pas l'espace de stockage avec quelqu'un d'autre, donc je suis le seul à modifier.
• git push pousse à un dépôt distant, de sorte que si jamais il est corrompu, je peux facilement le récupérer.
• j'ai dû créer des alias dans C:\Users avec mklink /D link target parce que certaines bibliothèques étaient pointées vers des emplacements absolus.

j'ai fait face à un problème similaire et j'ai créé un petit script pour le même. L'idée est d'utiliser Dropbox avec Git aussi simplement que possible. Actuellement, j'ai rapidement implémenté le code Ruby , et j'en ajouterai bientôt plus.

le script est accessible à https://github.com/nuttylabs/box-git .

une autre approche:

toutes les réponses jusqu'à présent, y compris @Dan answer qui est le plus populaire, abordent l'idée d'utiliser Dropbox pour centraliser un dépôt partagé au lieu d'utiliser un service axé sur git comme GitHub, bitbucket, etc.

mais, comme la question originale ne précise pas ce que "Git et Dropbox ensemble efficacement" signifie réellement, travaillons sur une autre approche: "Utilisant Dropbox pour synchroniser seulement le worktree."

comment a ces étapes:

1. dans le répertoire du projet, on crée un répertoire vide .git (par exemple mkdir -p myproject/.git )

2. un-sync le répertoire .git dans Dropbox. Si vous utilisez L'application Dropbox: allez dans Préférences, Sync, et" choose folders to sync", où le répertoire .git doit être non marqué. Cela permettra d'éliminer l' .git répertoire.

3. exécuter git init dans le répertoire du projet

cela fonctionne aussi si le .git existe déjà, alors ne faites que l'étape 2. Dropbox conservera cependant une copie des fichiers git sur le site web.

Étape 2 sera la cause de Dropbox ne pas synchroniser le git de la structure du système, qui est le résultat attendu de cette approche.

pourquoi un utiliser cette approche?

• les changements non-encore poussés auront une sauvegarde Dropbox, et ils seront synchronisés sur tous les appareils.

• dans le cas où Dropbox visse quelque chose lors de la synchronisation entre les appareils, git status et git diff sera pratique pour trier les choses.

• il économise de l'espace dans le compte Dropbox (toute l'histoire ne sera pas stockée il y a)

• il évite les préoccupations soulevées par @dubek et @Ates dans les commentaires sur la réponse de @Dan, et les préoccupations de @clu dans une autre réponse .

L'existence d'une distance de quelque part d'autre (github, etc.) fonctionnera très bien avec cette approche.

travailler sur différentes branches apporte quelques problèmes, qui doivent être pris en charge:

• un problème potentiel est d'avoir Dropbox (inutilement?) synchroniser potentiellement plusieurs fichiers lorsqu'on vérifie différentes branches.

• si deux ou plusieurs Dropbox synced dispositifs ont différentes branches cochées, les changements non engagés aux deux dispositifs peuvent être perdus,

une façon de contourner ces problèmes est d'utiliser git worktree pour conserver direction des extractions dans des répertoires distincts.

sans utiliser d'outils d'intégration tiers, je pourrais améliorer la condition un peu et utiliser DropBox et d'autres services de disque cloud similaires tels que SpiderOak avec Git.

le but est d'éviter la synchronisation au milieu de ces modifications de fichiers, car il peut télécharger un État partiel et puis le télécharger à nouveau, corrompant complètement votre état git.

pour éviter ce problème, j'ai fait:

1. Bundle my index git dans un fichier utilisant git bundle create my_repo.git --all .
2. définit un délai pour la surveillance du fichier, par exemple 5 minutes, au lieu d'un délai instantané. Cela réduit les chances que DropBox synchronise un État partiel au milieu d'un changement. Cela aide également beaucoup lors de la modification des fichiers sur le disque cloud à la volée (comme avec les applications de prise de notes instantanée).

ce n'est pas parfait car il n'y a aucune garantie qu'il ne va pas gâcher l'état git à nouveau, mais il aide et pour le moment je n'ai pas eu aucun problème.

pour mes 2 cents Dropbox fait seulement sence pour un usage personnel où vous ne voulez pas se donner la peine d'obtenir un hôte de repo central. Pour tout développement professionnel, vous allez probablement créer plus de problèmes que vous allez résoudre, comme ont été mentionnés plusieurs fois dans le thread déjà, Dropbox n'est pas conçu pour ce cas d'utilisation. Cela dit, une méthode parfaitement sûre pour décharger des dépôts sur Dropbox sans plugins ou outils tiers est d'utiliser des paquets. J'ai les alias suivants dans mon .gitconfig pour sauvegarder la saisie:

[alias]
        bundle-push = "!cd \"${GIT_PREFIX:-.}\" && if path=\"$(git config remote.\"\".url)\" && [ \"${path:0:1}\" = / ]; then git bundle create \"$path\" --all && git fetch \"\"; else echo \"Not a bundle remote\"; exit 1; fi #"
        bundle-fetch = "!cd \"${GIT_PREFIX:-.}\" && if path=\"$(git config remote.\"\".url)\" && [ \"${path:0:1}\" = / ]; then git bundle verify \"$path\" && git fetch \"\"; 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 \"\" ]; then echo \"File exist\"; exit 1; else git bundle create \"\" --all && git remote add -f \"\" \"$(realpath \"\")\"; fi #"

exemple:

# 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