Vous utilisez Git et Dropbox ensemble efficacement?

Comment utiliser efficacement Git et Dropbox ensemble?

Je pense que Git sur Dropbox est génial. Je l'utilise tout le temps. J'ai plusieurs ordinateurs (deux à la maison et un au travail) que j'utilise Dropbox comme référentiel nu central. Comme je ne veux pas l'héberger sur un service public et que je n'ai pas accès à un serveur sur lequel je peux toujours ssh, Dropbox s'en charge en se synchronisant (très rapidement) en arrière-plan.

La configuration est quelque chose comme ceci:

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

À partir de là, vous pouvez simplement cloner ce ~/Dropbox/git/project.gitque vous avez associé à votre compte Dropbox (ou avoir partagé ce répertoire avec des personnes), vous pouvez effectuer toutes les opérations Git normales et elles seront automatiquement synchronisées avec toutes vos autres machines.

J'ai écrit un article de blog, On Version Control , ( ancien lien ^mort ) sur mon raisonnement et la façon dont je configure mon environnement, il est basé sur mon expérience de développement Ruby on Rails , mais il peut être appliqué à n'importe quoi, vraiment.

La bonne façon de le faire est d'utiliser git-remote-dropbox: https://github.com/anishathalye/git-remote-dropbox

La création de votre propre référentiel nu dans Dropbox provoque de nombreux problèmes. Anish (le créateur de la bibliothèque) l' explique le mieux :

La cause première de ces problèmes est que le client de bureau Dropbox est conçu pour synchroniser des fichiers, pas des référentiels Git. Sans traitement spécial pour les référentiels Git, il ne conserve pas les mêmes garanties que Git. Les opérations sur le référentiel distant ne sont plus atomiques, et des opérations simultanées ou un timing malchanceux avec synchronisation peuvent entraîner un référentiel corrompu.

Les télécommandes Git traditionnelles exécutent du code côté serveur pour que cela fonctionne correctement, mais nous ne pouvons pas le faire.

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

Pour un utilisateur, c'est aussi simple que d'utiliser git-remote-dropbox, une aide à distance Git qui agit comme un pont bidirectionnel transparent entre Git et Dropbox et conserve toutes les garanties d'une télécommande Git traditionnelle. Il est même sûr à utiliser avec des dossiers partagés, il peut donc être utilisé pour la collaboration (yay repos privés illimités avec des collaborateurs illimités!).

Avec l'aide à distance, il est possible d'utiliser Dropbox comme une télécommande Git et de continuer à utiliser toutes les commandes Git normales comme git clone, git pull et git push, et tout fonctionnera comme prévu.

Cette réponse est basée sur l' expérience Mercurial , pas sur Git, mais cette expérience indique que l'utilisation de Dropbox de cette façon demande des référentiels corrompus s'il y a même une chance que vous mettiez à jour le même référentiel basé sur Dropbox à partir de différentes machines à différents moments (Mac, Unix, Windows dans mon cas).

Je n'ai pas de liste complète des choses qui peuvent mal tourner, mais voici un exemple spécifique qui m'a mordu. Chaque machine a sa propre notion de caractères de fin de ligne et comment les caractères majuscules / minuscules sont traités dans les noms de fichiers. Dropbox et Git / Mercurial gèrent cela légèrement différemment (je ne me souviens pas des différences exactes). Si Dropbox met à jour le référentiel derrière le dos de Git / Mercurial, presto, référentiel cassé. Cela se produit immédiatement et de manière invisible, donc vous ne savez même pas que votre référentiel est cassé jusqu'à ce que vous essayiez d'en récupérer quelque chose.

Après avoir creusé un désordre en faisant les choses de cette façon, j'ai utilisé la recette suivante avec beaucoup de succès et aucun signe de problème. Déplacez simplement votre référentiel 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 référentiel lui-même. Les deux sont gratuits, ce qui n'ajoute rien aux coûts, et chaque outil joue maintenant à ses points forts.

L'exécution de Git / Mercurial sur Dropbox n'ajoute rien à part le risque. Ne le fais pas.

En ce qui concerne les petites équipes utilisant Dropbox:

Si chaque développeur a son propre référentiel nu accessible en écriture sur Dropbox, qui est uniquement tiré vers d'autres développeurs, cela facilite le partage de code sans risque de corruption!

Ensuite, si vous voulez une «ligne principale» centralisée, vous pouvez demander à un développeur de gérer toutes les poussées vers lui à partir de son propre référentiel.

Je ne voulais pas mettre tous mes projets sous un seul référentiel Git, ni entrer et exécuter ce code pour chaque projet, j'ai donc créé un script Bash qui automatisera le processus. Vous pouvez l'utiliser sur un ou plusieurs répertoires - afin qu'il puisse faire le code de ce message pour vous ou qu'il puisse 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 que l'utilisation de Git et Dropbox soit la voie à suivre ... Pensez simplement aux caractéristiques des deux:

Git:

• Vous permet d'avoir un référentiel central
• Vous permet d'avoir votre propre référentiel avec vos propres modifications
• Vous permet d'envoyer et de recevoir des modifications depuis le référentiel central
• Permet à plusieurs personnes de modifier les mêmes fichiers et les fusionne ou vous demande de les fusionner s'il ne peut pas le faire
• Dispose de clients Web et de bureau pour autoriser l'accès au référentiel central

Dropbox:

• Conserve tout dans un référentiel central
• Vous permet d'avoir vos propres versions des fichiers sur le serveur
• Vous oblige à envoyer et recevoir des modifications à partir du référentiel central
• Si plusieurs personnes modifient les mêmes fichiers, le premier fichier validé est remplacé par des validations ultérieures, et aucune fusion ne se produit, ce qui est gênant (et certainement son plus grand inconvénient)
• Dispose de clients Web et de bureau pour permettre l'accès au référentiel central.

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

Nous sommes maintenant en 2015 et, il y a 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 de bureau et gère correctement plusieurs push simultanés vers un référentiel 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 les sauvegardes à distance chiffrées .

Le plus cool est que Dropbox ne synchronise PAS l'intégralité du conteneur TrueCrypt 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 permet une excellente utilisation du bloc chiffrement + synchronisation au niveau du bloc.

Deuxièmement, un conteneur crypté monolithique non seulement ajoute de la sécurité, mais réduit également les risques de corruption du référentiel .

Attention: Cependant, vous devez être très prudent de ne pas avoir le conteneur monté lorsque Dropbox est en cours d'exécution. Il peut également être difficile de résoudre les conflits si 2 clients différents archivent des versions différentes du conteneur. Donc, c'est pratique seulement pour une seule personne l'utilisant pour des sauvegardes, pas pour une équipe.

Installer:

• Créer un conteneur Truecrypt (plusieurs gigaoctets, c'est bien)
• Sous les préférences Truecrypt, décochez preserve modification timestamp *.
• Créez un dépôt comme mentionné ci-dessus par Dan ( https://stackoverflow.com/a/1961515/781695 )

Usage:

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

PS Décocher la preserve modification timestampdropbox indique 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 volumeread-only

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 flux de travail ressemble à ceci:

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

Ce sont mes 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'

Nous utilisons cette méthode (création d'un référentiel nu dans Dropbox) sur un dossier partagé .

Un petit groupe de développeurs peut extraire de ce référentiel nu synchronisé et créer un clone local. Une fois l'unité de travail terminée, nous repoussons à l'origine.

Une chose qui me manque est un bon moyen d'envoyer un e-mail avec les informations de modification une fois qu'un push vers l'origine se produit. Nous utilisons Google Wave pour suivre manuellement les modifications.

J'ai utilisé Mercurial de la manière recommandée et je vous exhorte à être prudent, surtout si l'une des machines diffère. Les forums Dropbox regorgent de plaintes concernant des problèmes de cas de nom de fichier mystérieux se présentant spontanément. Hg (et je suppose que Git) ne s'en apercevra pas ou ne se plaindra pas lors des enregistrements de routine et vous n'entendrez parler de la corruption que lorsqu'il se plaint d'un dépôt corrompu lorsque vous essayez de l'utiliser pour de vrai. Mauvaises nouvelles. J'aimerais pouvoir être plus précis sur le problème et ses solutions de contournement; J'essaie toujours de sortir de ce bordel moi-même.

Il existe également un projet open source (une collection de scripts multiplateforme [Linux, Mac, Win]) qui fait tous les détails de la gestion du référentiel 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'utilisation normale de git:

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

Consultez le wiki du projet et les manuels pour une référence de commande complète et des tutoriels.

Je stocke mes repo non Github sur Dropbox. Une mise en garde que j'ai rencontrée était la synchronisation après une réinstallation. Dropbox téléchargera les plus petits fichiers avant de passer aux plus gros. Pas de problème si vous commencez la nuit et revenez après le week-end :-)

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

Maintenant 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 le référentiel avec quelqu'un d'autre, je suis donc le seul à le modifier.
• git push pousse vers un référentiel distant, de sorte que si jamais il est corrompu, je peux facilement le récupérer.
• J'ai dû créer des alias C:\Usersavec mklink /D link targetcar certaines bibliothèques pointaient vers des emplacements absolus.

J'aime la réponse la plus votée de Dan McNevin. J'ai fini par faire la séquence des commandes git trop de fois et j'ai décidé de faire un script. Voici donc:

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

Le script nécessite uniquement un nom de projet. Il générera un référentiel git ~/Dropbox/git/sous le nom spécifié et poussera tout le contenu du répertoire actuel vers la branche principale d'origine nouvellement créée. Si plusieurs noms de projet sont fournis, l'argument de nom de projet le plus à droite sera utilisé.

Facultativement, l'argument de la commande -r spécifie la branche distante qui sera envoyée au maître d'origine. L'emplacement du maître d'origine du projet peut également être spécifié avec l'argument -m. Un fichier .gitignore par défaut est également placé dans le répertoire de la branche distante. Les valeurs par défaut du répertoire et du fichier .gitignore sont spécifiées dans le script.

Une autre approche:

Toutes les réponses à ce jour, y compris la réponse @Dan qui est la plus populaire, abordent l'idée d'utiliser Dropbox pour centraliser un référentiel partagé au lieu d'utiliser un service axé sur git comme github, bitbucket, etc.

Mais, comme la question d'origine ne spécifie pas ce que signifie réellement "Git et Dropbox ensemble efficacement", travaillons sur une autre approche: "Utiliser Dropbox pour synchroniser uniquement le worktree."

La procédure comporte ces étapes:

1. à l'intérieur du répertoire du projet, on crée un .gitrépertoire vide (par exemple mkdir -p myproject/.git)

2. désynchronisez le .gitrépertoire dans Dropbox. Si vous utilisez l'application Dropbox: allez dans Préférences, Synchroniser et "choisissez les dossiers à synchroniser", où le .gitrépertoire doit être non marqué. Cela supprimera le .gitrépertoire.

3. exécuter git initdans le répertoire du projet

Cela fonctionne également si le .gitexiste déjà, alors ne faites que l'étape 2. Dropbox gardera cependant une copie des fichiers git sur le site Web.

L'étape 2 empêchera Dropbox de synchroniser la structure du système git, ce qui est le résultat souhaité pour cette approche.

Pourquoi utiliser cette approche?

• Les modifications non encore poussées auront une sauvegarde Dropbox et elles seront synchronisées sur tous les appareils.

• Dans le cas où Dropbox gâche quelque chose lors de la synchronisation entre les appareils, git statuset git diffsera pratique pour trier les choses.

• Il économise de l'espace dans le compte Dropbox (tout l'historique n'y sera pas stocké)

• Cela é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 télécommande ailleurs (github, etc.) fonctionnera très bien avec cette approche.

Travailler sur différentes branches pose des problèmes qui doivent être résolus:

• Un problème potentiel est d'avoir Dropbox (inutilement?) Synchronisant potentiellement de nombreux fichiers lorsque l'on vérifie différentes branches.

• Si deux ou plusieurs appareils synchronisés Dropbox ont des branches différentes extraites, les modifications non validées sur les deux appareils peuvent être perdues,

Une façon de contourner ces problèmes consiste git worktreeà conserver les extractions de branche dans des répertoires distincts.

Pour mon 2 cents, Dropbox ne fait sens que pour un usage personnel où vous ne voulez pas vous soucier d'obtenir un hôte de dépôt central. Pour tout développement professionnel, vous créerez probablement plus de problèmes que vous n'en résoudrez, comme cela a déjà été mentionné à plusieurs reprises dans le fil, Dropbox n'est pas conçu pour ce cas d'utilisation. Cela dit, une méthode parfaitement sûre pour vider les référentiels sur Dropbox sans plugins ou outils tiers consiste à utiliser des bundles. J'ai les alias suivants .gitconfigpour sauvegarder la saisie:

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

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

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

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

Sans utiliser des outils d'intégration tiers, je pourrais améliorer un peu la condition et utiliser DropBox et d'autres services de disques 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 le téléchargera ensuite, corrompant complètement votre état git.

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

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

Ce n'est pas parfait car il n'y a aucune garantie qu'il ne gâchera plus l'état git, mais cela aide et pour le moment je n'ai eu aucun problème.

Sur MacOS, vous pouvez également simplement arrêter Dropbox, apporter vos modifications, puis relancer Dropbox. J'utilise la combinaison suivante et j'en suis très satisfaite:

Dans les deux (votre répertoire de projet géré par git local et votre référentiel git distant situé sur Dropbox) exécutez la commande suivante pour désactiver la compression automatique (qui est le principal problème avec la synchronisation de dropbox)

git config --global gc.auto 0

Ensuite, de temps en temps, compressez les référentiels avec dropbox désactivé. Par exemple, je fais ce qui suit dans mon bash-build-script chaque fois que je fais de nouvelles versions de mes applications.

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