Vous utilisez Git et Dropbox ensemble efficacement?

1133

Comment utiliser efficacement Git et Dropbox ensemble?

n1kh1lp
la source
2
Voir aussi le tutoriel de Bradley Wright .
Ron Romero
39
Si vous n'êtes qu'une petite équipe (jusqu'à 5 je pense), alors BitBucket fournit un hébergement gratuit pour les référentiels privés. Ironiquement, j'ai ensuite mon dépôt local sur DropBox, juste au cas où je passerais d'un ordinateur à l'autre lorsque je travaille sur quelque chose.
Mark Adamson
12
Je ne suis pas sûr que votre redondance de version soit ironique, mais elle est probablement très utile
silasdavis
2
Cette question n'est pas claire. Que signifie utiliser ces outils ensemble "efficacement"? Il est également trop large et susceptible de générer des réponses d'opinion.
3
Hé, pourriez-vous s'il vous plaît considérer ma réponse comme la bonne: stackoverflow.com/a/32215708/589667 . Cette bibliothèque que je mentionne dans ma réponse est un outil officiel construit par les développeurs de dropbox pour aider les gens à utiliser Git avec Dropbox.
clu

Réponses:

1401

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.

Dan McNevin
la source
61
Je me demande ce qui se passera si vous poussez vers le repo nu dropbox de deux machines en même temps. Si cela va provoquer une modification dans l'un des fichiers internes de git, dropbox vous montrera qu'il y a un conflit - mais que faites-vous alors? Choisissez simplement l'une des versions, puis appuyez à nouveau sur les deux machines (une par une)?
dubek
162
@dubek: vous finirez probablement par corrompre le dépôt nu partagé. Cette approche ne convient qu'à une petite équipe (deux dans mon cas) où les gens peuvent simplement crier sur les parois de leur cabine: "Hé! Personne ne pousse! Je pousse maintenant!".
Ates Goral
50
@Ates: au moins git est décentralisé, donc si vous parvenez à corrompre des choses, vous pouvez le restaurer à partir de la copie locale de quelqu'un. Si vous avez une grande équipe, il y a de fortes chances qu'il y ait suffisamment d'argent pour un dépôt hébergé quelque part.
rdrey
75
Je suis revenu sur cette page plus de cinq fois pour utiliser cette séquence exacte de commandes. Je ne les mémoriserai jamais, mais merci de les avoir fournis!
Jeremy Mack
32
@Jo: Ce n'est pas assez ghetto.
Ates Goral
128

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.

clu
la source
8
Je suis heureux de voir que quelqu'un a posté sur git-remote-dropbox sur cette question StackOverflow. Je me demande s'il existe un moyen de rapprocher cette réponse du sommet. La méthode recommandée par la réponse actuellement acceptée est assez dangereuse et peut entraîner une corruption du référentiel.
fwenom
1
c'est vraiment cool. je vais certainement le vérifier. mais quand je passe d'une boîte de développement à une autre et que je veux continuer à travailler sur un dépôt synchronisé, cette méthode ne fonctionnera que si je commets toujours mon travail lorsque je quitte la machine A et que je veux reprendre là où je m'étais arrêté machine B. ai-je raison? si tel est le cas, ce n'est pas idéal, car cela conduirait à une avalanche de commits "provisoires", dont on pourrait arguer qu'ils pollueront l'historique des commits du repo. peut-être que je ne peux pas avoir mon gâteau et le manger aussi!
bhu Boue vidya
1
@bhuBouevidya Non, ce n'est pas vrai. Vous n'avez pas besoin de valider votre travail pour que les modifications soient synchronisées. Tant que les fichiers sont enregistrés, les fichiers seront synchronisés. Fondamentalement, si vous avez un tas de fichiers modifiés sur une machine, les modifications seront synchronisées sur l'autre car Dropbox se soucie simplement de ce qui a été enregistré sur le disque.
clu
2
@clu: Oui, vous devez valider votre travail et pousser. Tout ce que fait git-remote-dropbox est d'agir comme un assistant git remote. Tout comme les autres télécommandes, vos validations locales ne seront pas poussées vers la télécommande tant qu'une poussée n'aura pas été effectuée. La façon d'obtenir des fichiers modifiés localement dans le référentiel local afin qu'ils puissent être poussés est de faire un commit. Dropbox ne saura rien de vos fichiers qui ne se trouvent pas dans le référentiel.
Fourmis
2
Juste curieux si git-remote-dropbox est multi-plateforme ... Je vois qu'il utilise python, et je sais que certains autres trucs en python pour Dropbox ne sont pas multi-plateformes, par exemple sous OS X, les trucs en ligne de commande ne sont pas compatibles.
Michael
89

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.

Bradjcox
la source
13
Je pense que le dépôt git est suffisamment robuste pour ne pas se corrompre. Mon expérience (plus d'un an d'utilisation, principalement mono-utilisateur, multi-plateforme, multi-ordinateur, plusieurs devs), est que le dépôt de git n'est pas facilement corrompu. Dans git, seules les informations sont ajoutées au référentiel, les fichiers existants sont laissés seuls 99,9% du temps (les fichiers mutables sont généralement faciles à inspecter manuellement). J'ai parfois vu des cas où un pointeur de branche a été écrasé, mais cela peut être facilement vu (c'est-à-dire "branche (copie en conflit de XXX)")) et supprimé (aucune correction réelle n'est nécessaire, en fait).
Egon
1
@tc: Vous avez raison, lors de la récupération de place, les informations non accessibles sont supprimées dans git. Cependant, je suppose que pour la plupart des cas pratiques, cela ne nuit pas à la robustesse: seules les informations inaccessibles datant de plus de 2 semaines sont affectées (ce qui laisse amplement de temps à DropBox pour se synchroniser). Et à ce moment d'un tel conflit, je soupçonne que la plupart des informations seront disponibles sous forme emballée et non emballée.
Egon
Je pense que le scénario de partage de code sans référentiel central (décrit dans une réponse ci-dessous) sauverait un des corruptions possibles en raison des mises à jour simultanées du répertoire dans la boîte de dépôt. Si l'on a besoin d'un référentiel central, il pourrait être géré séparément (et séparé du dropbox); dropbox contiendrait des dépôts de travail personnels (ce qui est également pratique car vous pouvez mettre à jour / extraire de temps en temps du référentiel source de quelqu'un d'autre dans votre équipe sur lequel vous avez basé votre travail). (En fait, j'envisage d'utiliser des darcs dans un tel cadre.)
imz - Ivan Zakharyaschev
5
+1 Si vous ne souhaitez pas héberger vos référentiels en public, utilisez Bitbucket , les référentiels privés sont gratuits pour les équipes jusqu'à 5 utilisateurs.
Christian Specht
Une chose que j'ai remarquée entre une machine Windows et une machine OSX est que les autorisations de fichiers peuvent provoquer des problèmes de différence. Vous pouvez désactiver les autorisations dans Git en utilisant: "git config core.fileMode false"
devdrc
16

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.

teh_senaus
la source
1
Tant mieux! De plus, pour protéger la corruption du référentiel de plusieurs écritures, vous pouvez facilement créer des dépôts MULTIPLES et synchroniser uniquement leurs dossiers .git! Tout ce dont vous avez besoin en un instant - c'est de tirer de l'origine souhaitée! Grand homme P-to-P! Vous comprenez la philosophie décentralisée de git!
Brian Haak
16

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
Eli
la source
15

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 ...

Coyote21
la source
Dropbox est juste une bonne option pour un dépôt central. S'il est placé dans un dossier partagé , il fonctionne même pour les groupes.
mac
1
Oui, mais vous n'aurez pas les mêmes fonctionnalités de fusion que dans git, en fait, si quelqu'un modifie le même fichier que le vôtre, et qu'il enregistre le fichier après vous, vos modifications sont perdues, sauf si vous allez sur l'interface Web et téléchargez l'ancienne version (votre version).
Coyote21
8
C'est faux. Dropbox ne supprime pas les conflits. Il modifie le nom de fichier d'une modification et utilise l'autre pour la continuité. Vous pouvez les fusionner manuellement si vous le souhaitez. C'est un bon compromis et ne perd pas de données. dropbox.com/help/36
Clueless
6
Oui, mais comme il s'agit de code, moins je passe de temps à fusionner de fichiers, plus je peux produire de code, et dans une base de code normale, il peut y avoir des centaines de conflits à la fois, selon les dimensions du projet, et ce serait un cauchemar de fusionner ensuite un par un, même à l'aide d'un outil de fusion comme WinMerge (ou quelque chose de similaire).
Coyote21
15

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"
merlin2011
la source
2
Ce serait bien si un mod fusionnait toutes les nombreuses questions git-with-dropbox sur stackexchange sous un superthread qui mentionne d'abord les dernières choses.
Blair Houghton
9

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

utilisateur
la source
Serait-il très différent si vous utilisez une image de fichier .dmg crypté macos , le temps de synchronisation serait-il encore approximativement proportionnel aux changements?
IBrum
@IBrum Désolé, je ne l'ai pas essayé avec un fichier .dmg
utilisateur
7

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'
Michiel de Mare
la source
Je n'utiliserais probablement pas la dernière chose comme un alias, plutôt un script shell. Sinon, j'aime beaucoup ça. Crédit supplémentaire pour l'utilisation awk.
pauljohn32
6

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.

dengel
la source
81
Quelqu'un utilise Google Wave?
Kristopher Johnson
6

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.

Brad Cox
la source
J'ai eu le même problème avec mercurial
Tomba
git vérifie beaucoup plus les corruptions que les autres par conception. Donc, au moins, vous saurez quand cela se produira et pourrez corriger le problème.
Anders
6

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.

Péter Szilágyi
la source
4

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

Ben
la source
4

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.
Mikaël Mayer
la source
3

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.

ChisholmKyle
la source
3

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.

IBrum
la source
En tant que personne travaillant sur des fichiers qu'il serait agréable de contrôler la version, mais également modifiable sur un iPad (via la synchronisation Dropbox), cette réponse couvre ce cas d'utilisation.
Vagari
Suivi rapide, le comportement actuel de Dropbox est différent. Supprimer simplement et dire à Dropbox de ne pas se synchroniser signifie le contraire, reste dans le cloud, supprime du local. Mais il y a une réponse de superutilisateur avec une solution. superuser.com/a/1527145/109561 Dans mon cas (sur Mac) les drapeaux suivants le fichier pour ignorer, xattr -w com.dropbox.ignored 1 /path/to/somewhere.
Vagari
3

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
Niklas Holm
la source
2

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.

Kiran Madipally
la source
0

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.

généreux
la source
0

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\""
berbie
la source