Question Utiliser Git et Dropbox ensemble efficacement?


Comment est-ce que j'utilise Git et Dropbox ensemble efficacement?


1062
2017-12-25 08:41


origine


Réponses:


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 un dépôt central nu. Comme je ne veux pas l'héberger sur un service public et que je n'ai pas accès à un serveur que je puisse toujours utiliser, Dropbox se charge de cela en se synchronisant (très rapidement) en arrière-plan.

Le programme d'installation 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

De là, vous pouvez simplement cloner ~/Dropbox/git/project.git que vous avez associé à votre compte Dropbox (ou que vous avez 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 comment j'ai mis en place mon environnement, il est basé sur mon Ruby sur Rails expérience de développement, mais il peut être appliqué à n'importe quoi, vraiment.


1350
2017-12-25 17:10



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

Créer votre propre repo nu dans Dropbox cause beaucoup de problèmes. Anish (le créateur de la bibliothèque) explique le mieux:

La cause première 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 pour autant   traitement spécial pour les dépôts Git, il ne maintient pas le même   garanties comme Git. Les opérations sur le référentiel distant ne sont plus   opérations atomiques et simultanées ou timing malchanceux avec   la synchronisation peut 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 faire cela.

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

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

Avec l'aide à distance, il est possible d'utiliser Dropbox comme une télécommande Git   et continuez à utiliser toutes les commandes régulières de Git comme git clone, git   tirer, et git pousser, et tout va fonctionner comme prévu.


86
2017-08-25 23:25



Cette réponse est basée sur Mercuriel expérience, pas Git, mais cette expérience dit utiliser 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 référentiel Dropbox à partir de différentes machines à différents moments (Mac, Unix, Windows dans mon cas ).

Je n'ai pas une 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 ça différemment (je ne me souviens pas des différences exactes). Si Dropbox met à jour le dépôt derrière le dos, presto, référentiel brisé de Git / Mercurial. Cela se produit immédiatement et de manière invisible, donc vous ne savez même pas que votre dépôt est cassé tant que vous n'avez pas essayé de 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èmes. Déplacez simplement votre dépôt hors de Dropbox. Utilisez Dropbox pour tout le reste; Documentation, Fichiers JAR, tout ce que vous s'il vous plaît. Et utilise GitHub (Git) ou Bitbucket (Mercurial) pour gérer le référentiel lui-même. Les deux sont gratuits, donc cela n'ajoute rien aux coûts, et chaque outil joue maintenant à ses points forts.

Lancer Git / Mercurial au dessus de Dropbox n'ajoute rien sauf le risque. Ne fais pas ça.


85
2018-05-01 20:48



En ce qui concerne les petites équipes utilisant Dropbox:

Si chaque développeur possède son propre référentiel en écriture sur Dropbox, qui est tirer seulement à 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 de son propre dépôt.


16
2017-12-04 12:27



Je ne voulais pas mettre tous mes projets sous un seul dépôt Git, je n'avais pas non plus envie d'y aller et d'exécuter ce code pour chaque projet, alors j'ai fait un Frapper script qui automatisera le processus. Vous pouvez l'utiliser sur un ou plusieurs répertoires - afin qu'il puisse faire le code dans ce poste 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

16
2017-12-02 18:37



Je ne pense pas que l'utilisation de Git et Dropbox soit la solution ... Pensez aux fonctionnalités des deux:

Git:

  • Vous permet d'avoir un référentiel central
  • Vous permet d'avoir votre propre dépôt avec vos propres changements
  • Vous permet d'envoyer et de recevoir des modifications depuis le référentiel central
  • Permet à plusieurs personnes de changer les mêmes fichiers et les fusionne ou vous demande de les fusionner s'il ne peut pas le faire
  • A des 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 dans le serveur
  • Vous force à 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 n'a lieu, ce qui est gênant (et certainement son plus grand inconvénient)
  • A des clients Web et de bureau pour autoriser 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 à Git, c'est-à-dire, d'avoir des fichiers publics et privés ...


15
2018-05-26 09:50



Nous sommes en 2015, et il y a trois jours, un nouvel outil basé sur API Dropbox v2 a été créé pour utiliser git en toute sécurité sur Dropbox. Il fonctionne contre l'API plutôt que d'utiliser le client de bureau et gère correctement plusieurs poussées simultanées 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"

14
2017-08-23 07:31



J'utilise Mercurial (ou Git) + TrueCrypt + Dropbox pour chiffré éloigné sauvegardes.

Le plus cool est que Dropbox ne synchronise pas l'ensemble 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 si elle est cryptée, la combinaison de TrueCrypt + Dropbox fait un excellent usage de la synchronisation de bloc + chiffrement de bloc.

Deuxièmement, un conteneur crypté monolithique ne fait pas qu'ajouter de la sécurité, il réduit également les chances de stockage la corruption .

Mise en garde: Cependant, vous devez faire très attention de ne pas monter le conteneur lorsque Dropbox est en cours d'exécution. Il peut également être difficile de résoudre les conflits si deux clients différents enregistrent différentes versions dans le conteneur. Donc, c'est pratique seulement pour une seule personne qui l'utilise pour des sauvegardes, pas pour une équipe.

Installer:

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

Usage:

  • Quitter Dropbox
  • Montez le conteneur, appuyez sur vos modifications, démontez
  • Exécuter la boîte de dépôt

P.S. Décocher la 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 modifiez aucun fichier. Si vous ne voulez pas que cela se produise, montez simplement le volume read-only


8
2018-03-03 16:18



J'utilise Mercurial de la manière recommandée et je vous conseille d'être prudent, surtout si l'une des machines diffère. Les forums Dropbox sont pleins de plaintes de problèmes mystérieux de cas de nom de fichier se présentant spontanément. Hg (et je présume Git) ne remarquera pas ou ne se plaindra pas pendant les vérifications de routine et vous n'entendrez parler de la corruption quand il se plaint d'un repo corrompu lorsque vous essayez de l'utiliser pour de vrai. Mauvaises nouvelles. Je souhaite que je pourrais être plus précis sur le problème et ses solutions de contournement; J'essaie toujours de sortir de ce pétrin moi-même.


6
2018-03-04 11:42



J'aime la réponse de Dan McNevin! J'utilise 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'

6
2018-02-17 10:01



Nous utilisons cette méthode (créer un référentiel nu dans Dropbox) sur un dossier de partage.

Un petit groupe de développeurs peut tirer à partir de ce référentiel 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 que l'envoi a été envoyé à l'origine. Nous utilisons Google Wave pour suivre manuellement les modifications.


5
2018-06-14 13:32