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) sur lesquels j'utilise Dropbox en tant que référentiel nu central. Puisque 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 aller en ssh, Dropbox s'en occupe en effectuant une synchronisation (très rapidement) en arrière-plan.
La configuration ressemble à 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 ~/Dropbox/git/project.git que vous avez associé à votre compte Dropbox (ou 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, Sur le contrôle de version, ( ancien lien mort) sur mon raisonnement et la façon dont j’ai configuré 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 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 pose de nombreux problèmes. Anish (le créateur de la bibliothèque) explique le mieux :
La cause première de ces problèmes est que le client de bureau Dropbox est conçu pour la synchronisation de fichiers, et non de référentiels Git. Sans traitement particulier 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 une synchronisation malencontreuse avec synchronisation peuvent entraîner la corruption du référentiel.
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 s’il ya plusieurs utilisateurs et opérations simultanées!
Pour un utilisateur, c’est aussi simple que d’utiliser git-remote-dropbox, un assistant distant Git qui fait office de pont bidirectionnel transparent entre Git et Dropbox et maintient toutes les garanties d’un système distant distant Git. Il est même sûr de l’utiliser avec des dossiers partagés, ce qui permet de l’utiliser pour la collaboration (yay reposants privés illimités avec collaborateurs illimités!).
Avec l’assistant distant, il est possible d’utiliser Dropbox en tant que télécommande Git et de continuer à utiliser toutes les commandes Git habituelles, telles que git clone, git pull et git Push, et tout fonctionnera comme prévu.
Cette réponse est basée sur Mercurial expérience, pas sur Git, mais cette expérience indique que l'utilisation de Dropbox de cette façon consiste à demander des référentiels endommagés s'il est même possible que vous mettiez à jour le même référentiel basé sur Dropbox à partir de différentes sources. machines à différents moments (Mac, Unix, Windows dans mon cas).
Je n'ai pas une liste complète des problèmes qui peuvent survenir, mais voici un exemple spécifique qui m'a mordu. Chaque machine a sa propre notion de caractères de fin de ligne et de traitement des majuscules/minuscules dans les noms de fichiers. Dropbox et Git/Mercurial traitent 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, le référentiel est cassé. Cela se produit immédiatement et de manière invisible, de sorte que vous ne savez même pas que votre référentiel est cassé tant que vous n'avez pas essayé de récupérer quelque chose.
Après avoir réussi à résoudre ce problème, j’utilise 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 solutions sont gratuites, ce qui n’ajoute rien aux coûts et chaque outil exploite désormais ses atouts.
L'exécution de Git/Mercurial au-dessus de Dropbox n'ajoute rien sauf le risque. Ne le fais pas.
Je ne voulais pas placer tous mes projets dans un même référentiel Git, ni 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 annuaires pour qu’il puisse faire le code de cet article à votre place ou le faire pour 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
En ce qui concerne les petites équipes utilisant Dropbox:
Si chaque développeur dispose de son propre référentiel nu accessible en écriture sur Dropbox, qui est extraction uniquement pour les autres développeurs, cela facilite le partage de code sans risque de corruption!
Ensuite, si vous souhaitez une "ligne principale" centralisée, vous pouvez faire en sorte qu'un développeur gère tous les envois depuis son propre référentiel.
Je ne pense pas que l'utilisation de Git et Dropbox soit la solution idéale. Pensez simplement aux fonctionnalités 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 à partir du 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
- Possède des clients Web et de bureau pour permettre 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 constitue sans aucun doute son plus gros inconvénient).
- Possède des clients Web et de bureau pour permettre l'accès au référentiel central.
Et si vous ne souhaitez pas partager certains de vos fichiers, pourquoi ne pas les chiffrer? Et puis, vous pourriez obtenir le plus gros avantage de Dropbox pour Git, à savoir avoir des fichiers publics et privés ...
Nous sommes maintenant en 2015 et il y a trois jours, un nouvel outil basé sur API Dropbox v2 a été créé pour utiliser en toute sécurité git sur Dropbox. Cela fonctionne avec l'API plutôt que d'utiliser le client de bureau et gère correctement plusieurs envois simultanés vers un référentiel hébergé dans un dossier partagé.
Une fois configuré, il vous 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 cryptées ).
Le plus intéressant est que Dropbox NE synchronise PAS l’ensemble du conteneur TrueCrypt si vous modifiez une petite partie de votre code. La durée de synchronisation est à peu près proportionnelle à la quantité de changements. Même si elle est cryptée, la combinaison de TrueCrypt + Dropbox permet une excellente utilisation du chiffrement par bloc + de la synchronisation au niveau du bloc.
Deuxièmement, un conteneur crypté monolithique non seulement ajoute une sécurité, mais réduit également les risques de référentiel corruption .
Attention: Cependant, vous devez faire très attention de ne pas avoir le conteneur monté pendant que Dropbox est en cours d'exécution. La résolution des conflits peut également s'avérer difficile si deux clients différents archivent des versions différentes du conteneur. Donc, ce n'est pratique que pour une seule personne qui l'utilise pour des sauvegardes, pas pour une équipe.
Installer:
- Créer un conteneur Truecrypt (plusieurs gigaoctets, c'est bien)
- Sous Préférences de cryptographie, décochez la case
preserve modification timestamp*. - Créez un référentiel tel que mentionné ci-dessus par Dan ( https://stackoverflow.com/a/1961515/781695 )
Usage:
- Quitter Dropbox
- Montez le conteneur, poussez vos modifications, démontez
- Exécuter dropbox
P.S. Décocher la preserve modification timestamp indique à la boîte de dépôt que le fichier a été modifié et qu'il devrait être synchronisé. Notez que le montage du conteneur modifie l'horodatage même si vous n'y modifiez aucun fichier. Si vous ne voulez pas que cela se produise, montez simplement le volume en tant que read-only
J'utilise Mercurial de la manière recommandée et je vous exhorte à faire preuve de prudence, en particulier si l'une des machines est différente. Les forums Dropbox regorgent de plaintes concernant de mystérieux problèmes de cas de nom de fichier survenant spontanément. Hg (et je présume que Git) ne remarquera rien ni ne se plaindra lors des vérifications de routine et vous entendrez parler uniquement de corruption quand il se plaint d'un dépôt corrompu lorsque vous essayez de l'utiliser réellement. Mauvaises nouvelles. Je souhaiterais pouvoir être plus précis sur le problème et ses solutions de contournement; J'essaie encore de creuser moi-même dans ce gâchis.
J'aime la réponse de Dan McNevin! J'utilise aussi Git et Dropbox ensemble 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'
Il existe également un projet open source (une collection de scripts inter-plateformes [Linux, Mac, Win]) qui effectue 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
L'utilisation de l'échantillon est:
$ gitbox create myapp
Creating empty repository...
Initializing new repository...
Repository successfully created.
$ gitbox clone myapp
Cloning repository...
Repository successfully cloned.
Après quoi 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 connaître la référence de commande complète et les didacticiels.
Nous utilisons cette méthode (création d'un référentiel nu dans Dropbox) sur un dossier de partage.
Un petit groupe de développeurs peut extraire de ce référentiel nu synchronisé et créer un clone local. Une fois que l'unité de travail est terminée, nous repoussons à l'origine.
Une chose me manque, c'est un bon moyen d'envoyer un courrier électronique avec les informations sur le jeu de modifications une fois qu'un envoi vers l'origine a eu lieu. Nous utilisons Google Wave pour suivre manuellement les modifications.
Je stocke mes dépôts non Github sur Dropbox. Un problème que j'ai rencontré est la synchronisation après une réinstallation. Dropbox téléchargera les plus petits fichiers avant de passer aux plus gros. Ce n'est pas un problème si vous commencez la nuit et revenez après le week-end :-)
Mon fil de discussion - http://forums.dropbox.com/topic.php?id=29984&replies=6
J'aime la réponse votée par Dan McNevin. J'ai fini par faire la séquence de commandes git trop de fois et j'ai décidé de faire un script. Alors la voici:
#!/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 dans ~/Dropbox/git/ sous le nom spécifié et transmettra l'intégralité du contenu du répertoire actuel à la nouvelle branche maître d'origine. Si plus d'un nom de projet est donné, l'argument de nom de projet le plus à droite sera utilisé.
En option, l'argument de la commande -r spécifie la branche distante qui sera transférée au maître d'origine. L'emplacement du projet Origin master 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.
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 Pushpasse dans un référentiel distant, afin que, s'il est corrompu, je puisse le récupérer facilement.- Je devais créer des alias dans
C:\Usersavecmklink /D link target, car certaines bibliothèques étaient dirigées vers des emplacements absolus.
Une autre approche:
Toutes les réponses à ce jour, y compris @ Dan Dan qui est la plus populaire, évoquent 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 initiale ne précise pas ce que signifie réellement utiliser "Git et Dropbox ensemble efficacement", travaillons sur une autre approche: "Utiliser Dropbox pour synchroniser uniquement la structure de travail".
Le comment faire a ces étapes:
dans le répertoire du projet, on crée un répertoire _
.git_ vide (par exemple _mkdir -p myproject/.git_)désynchronisez le répertoire _
.git_ dans Dropbox. Si vous utilisez l'application Dropbox: allez dans Préférences, Synchroniser et "choisir les dossiers à synchroniser", où le répertoire _.git_ doit être désélectionné. Cela supprimera le répertoire _.git_.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. Cependant, Dropbox conservera 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 insérées auront une sauvegarde Dropbox et seront synchronisées sur tous les appareils.
Au cas où Dropbox visse quelque chose lors de la synchronisation entre appareils, _
git status_ et _git diff_ sera pratique pour régler les problèmes.Cela économise de l'espace dans le compte Dropbox (l'historique complet n'y sera pas stocké)
Cela évite les soucis soulevés par @dubek et @Ates dans les commentaires sur la réponse de @Dan, ainsi que par @clu dans autre réponse .
L’existence d’un site distant (github, etc.) fonctionnera parfaitement avec cette approche.
Travailler dans différentes branches soulève des problèmes qui doivent être résolus:
Un problème potentiel est que Dropbox (inutilement?) Synchronise potentiellement plusieurs fichiers lorsque l’on extrait différentes branches.
Si deux branches ou plus synchronisées sur Dropbox ont des branches différentes extraites, les modifications non validées des deux appareils peuvent être perdues.
Une solution à ces problèmes consiste à utiliser git worktree pour conserver les extractions de branche dans des répertoires distincts.
J'ai été confronté à un problème similaire et j'ai créé un petit script. L'idée est d'utiliser Dropbox avec Git le plus simplement possible. Actuellement, j'ai rapidement implémenté le code Ruby , et j'en ajouterai bientôt d'autres.
Le script est accessible à l'adresse https://github.com/nuttylabs/box-git.
Pour mes 2 centimes, Dropbox n’est conçu que pour un usage personnel où vous ne voulez pas vous donner la peine d’avoir un hébergeur central. Pour tout développement professionnel, vous allez probablement créer plus de problèmes que vous n'en résolverez, comme cela a déjà été mentionné à plusieurs reprises dans le fil de discussion, Dropbox n'est pas conçu pour ce cas d'utilisation. Cela dit, une méthode parfaitement sûre pour vider des référentiels sur Dropbox sans plug-in ni outil tiers est d'utiliser des bundles. J'ai les alias suivants dans mon .gitconfig pour 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
Sans utiliser des outils d'intégration tiers, je pourrais améliorer légèrement la situation et utiliser DropBox et d'autres services de disque en nuage similaires tels que SpiderOak avec Git.
L'objectif est d'éviter la synchronisation au milieu de ces modifications de fichiers, car il peut télécharger un état partiel et le restituera ensuite, corrompant ainsi complètement votre état git.
Pour éviter ce problème, j'ai:
- Regroupez mon index git dans un fichier en utilisant
git bundle create my_repo.git --all. - Définissez un délai pour la surveillance du fichier, par exemple 5 minutes, au lieu d’instantané. Cela réduit les chances que DropBox synchronise un état partiel au milieu d'une modification. Cela aide également beaucoup lorsque vous modifiez des fichiers sur le disque en nuage à la volée (comme avec des applications de prise de notes avec enregistrement instantané).
Ce n'est pas parfait car il n'y a aucune garantie qu'il ne gâchera pas encore l'état d'esprit, mais ça aide et pour le moment je n'ai eu aucun problème.