¿Usando Git y Dropbox juntos de manera efectiva?

¿Cómo uso Git y Dropbox juntos de manera efectiva?

Creo que Git en Dropbox es genial. Lo uso todo el tiempo. Tengo varias computadoras (dos en casa y una en el trabajo) que utilizo Dropbox como repositorio central. Como no quiero alojarlo en un servicio público y no tengo acceso a un servidor al que siempre pueda enviar mensajes, Dropbox se encarga de esto sincronizándolo (muy rápidamente) en segundo plano.

La configuración es algo como esto:

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

A partir de ahí, puede simplemente clonar ~/Dropbox/git/project.gitque ha asociado con su cuenta de Dropbox (o ha compartido este directorio con personas), puede hacer todas las operaciones normales de Git y se sincronizarán con todas sus otras máquinas automáticamente.

Escribí una publicación de blog, En el Control de versiones , ( viejo enlace ^muerto ) sobre mi razonamiento y cómo configuré mi entorno, se basa en mi experiencia de desarrollo de Ruby on Rails , pero realmente se puede aplicar a cualquier cosa.

La forma correcta de hacerlo es usar git-remote-dropbox: https://github.com/anishathalye/git-remote-dropbox

Crear su propio repositorio desnudo en Dropbox causa muchos problemas. Anish (el creador de la biblioteca) lo explica mejor :

La causa raíz de estos problemas es que el cliente de escritorio de Dropbox está diseñado para sincronizar archivos, no repositorios de Git. Sin un manejo especial para los repositorios de Git, no mantiene las mismas garantías que Git. Las operaciones en el repositorio remoto ya no son atómicas, y las operaciones concurrentes o el tiempo desafortunado con sincronización pueden resultar en un repositorio dañado.

Los controles remotos Git tradicionales ejecutan código en el lado del servidor para que esto funcione correctamente, pero no podemos hacer eso.

Solución: es posible resolver esto correctamente. ¡Es posible usar Git con Dropbox y tener las mismas garantías de seguridad y consistencia que un control remoto tradicional de Git, incluso cuando hay múltiples usuarios y operaciones simultáneas!

Para un usuario, es tan simple como usar git-remote-dropbox, un ayudante remoto de Git que actúa como un puente bidireccional transparente entre Git y Dropbox y mantiene todas las garantías de un control remoto tradicional de Git. Incluso es seguro de usar con carpetas compartidas, por lo que se puede usar para la colaboración (yay repositorios privados ilimitados con colaboradores ilimitados!

Con el ayudante remoto, es posible usar Dropbox como un control remoto Git y continuar usando todos los comandos Git regulares como git clone, git pull y git push, y todo funcionará como se esperaba.

Esta respuesta se basa en la experiencia de Mercurial , no en Git, pero esta experiencia dice que usar Dropbox de esta manera es pedir repositorios corruptos si existe la posibilidad de que actualices el mismo repositorio basado en Dropbox desde diferentes máquinas en varias ocasiones (Mac, Unix, Windows en mi caso).

No tengo una lista completa de las cosas que pueden salir mal, pero aquí hay un ejemplo específico que me mordió. Cada máquina tiene su propia noción de caracteres de final de línea y cómo se manejan los caracteres en mayúscula / minúscula en los nombres de archivo. Dropbox y Git / Mercurial manejan esto de manera ligeramente diferente (no recuerdo las diferencias exactas). Si Dropbox actualiza el repositorio detrás de Git / Mercurial, presto, repositorio roto. Esto sucede de forma inmediata e invisible, por lo que ni siquiera sabe que su repositorio está roto hasta que intenta recuperar algo de él.

Después de desenterrar un desastre haciendo las cosas de esta manera, he estado usando la siguiente receta con gran éxito y sin signos de problemas. Simplemente mueva su repositorio fuera de Dropbox. Usa Dropbox para todo lo demás; documentación, archivos JAR , cualquier cosa que desee. Y use GitHub (Git) o Bitbucket (Mercurial) para administrar el repositorio en sí. Ambos son gratuitos, por lo que esto no agrega nada a los costos, y cada herramienta ahora aprovecha sus puntos fuertes.

Ejecutar Git / Mercurial encima de Dropbox no agrega nada, excepto el riesgo. No lo hagas

Con respecto a los equipos pequeños que usan Dropbox:

Si cada desarrollador tiene su propio repositorio desnudo de escritura en Dropbox, que se extrae solo para otros desarrolladores, entonces esto facilita el intercambio de código sin riesgo de corrupción.

Luego, si desea una 'línea principal' centralizada, puede hacer que un desarrollador administre todos los impulsos desde su propio repositorio.

No quería poner todos mis proyectos en un solo repositorio de Git, ni quería entrar y ejecutar este código para cada proyecto, así que hice un script Bash que automatizará el proceso. Puede usarlo en uno o en varios directorios, por lo que puede hacer el código en esta publicación por usted o puede hacerlo en varios proyectos a la vez.

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

No creo que usar Git y Dropbox sea el camino a seguir ... Solo piense en las características de ambos:

Git:

• Te permite tener un repositorio central
• Le permite tener su propio repositorio con sus propios cambios.
• Le permite enviar y recibir cambios desde el repositorio central
• Permite que varias personas cambien los mismos archivos y los fusiona o le pide que los fusione si no puede hacerlo
• Tiene clientes web y de escritorio para permitir el acceso al repositorio central

Dropbox:

• Mantiene todo en un repositorio central
• Le permite tener sus propias versiones de los archivos en el servidor
• Obliga a enviar y recibir cambios desde el repositorio central
• Si varias personas cambian los mismos archivos, el primer archivo confirmado se reemplaza con confirmaciones posteriores, y no se produce la fusión, lo cual es problemático (y definitivamente su mayor desventaja)
• Tiene clientes web y de escritorio para permitir el acceso al repositorio central.

Y si le preocupa compartir algunos de sus archivos, ¿por qué no cifrarlos? Y luego podría obtener la mayor ventaja de Dropbox to Git, es decir, tener archivos públicos y privados ...

Ahora es 2015, y desde hace tres días, se creó una nueva herramienta basada en Dropbox API v2 para usar git de forma segura en Dropbox. Funciona en contra de la API en lugar de usar el cliente de escritorio, y maneja correctamente múltiples empujes simultáneos a un repositorio alojado en una carpeta compartida.

Una vez configurado, permite configurar un control remoto git exactamente como cualquier otro control remoto git.

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

Uso Mercurial (o Git) + TrueCrypt + Dropbox para copias de seguridad remotas cifradas .

Lo mejor es que Dropbox NO sincroniza todo el contenedor TrueCrypt si modifica una pequeña porción de su código. El tiempo de sincronización es aproximadamente proporcional a la cantidad de cambios. Aunque está encriptado, la combinación de TrueCrypt + Dropbox hace un excelente uso de cifrado de bloque + sincronización de nivel de bloque.

En segundo lugar, un contenedor encriptado monolítico no solo agrega seguridad, sino que también reduce las posibilidades de corrupción del repositorio .

Precaución: Sin embargo, debe tener mucho cuidado de no tener el contenedor montado mientras se ejecuta Dropbox. También puede ser un problema resolver conflictos si 2 clientes diferentes registran versiones diferentes en el contenedor. Por lo tanto, es práctico solo para una sola persona que lo usa para copias de seguridad, no para un equipo.

Preparar:

• Cree un contenedor Truecrypt (varios Gigabytes están bien)
• En las preferencias de Truecrypt, desmarque preserve modification timestamp*.
• Cree un repositorio como se menciona anteriormente por Dan ( https://stackoverflow.com/a/1961515/781695 )

Uso:

• Salir de Dropbox
• Monta el contenedor, empuja tus cambios, desmonta
• Ejecutar Dropbox

PD Desmarcando el preserve modification timestampdropbox le dice que el archivo ha sido modificado y debe sincronizarse. Tenga en cuenta que el montaje del contenedor modifica la marca de tiempo incluso si no cambia ningún archivo en él. Si no desea que eso suceda, simplemente monte el volumen comoread-only

¡Me encanta la respuesta de Dan McNevin! Ahora también estoy usando Git y Dropbox juntos, y estoy usando varios alias en mi .bash_profile para que mi flujo de trabajo se vea así:

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

Estos son mis 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'

Usamos este método (crear un repositorio desnudo en Dropbox) en una carpeta compartida .

Un pequeño grupo de desarrolladores puede extraer de ese repositorio sincronizado desnudo y crear un clon local. Una vez que la unidad de trabajo está hecha, regresamos al origen.

Una cosa que me falta es una buena forma de enviar un correo electrónico con la información del conjunto de cambios una vez que se produce un impulso al origen. Estamos utilizando Google Wave para realizar un seguimiento manual de los cambios.

He estado usando Mercurial de la manera recomendada e insto a que tenga cuidado, especialmente si alguna de las máquinas difiere. Los foros de Dropbox están llenos de quejas de problemas misteriosos de casos de nombre de archivo que aparecen espontáneamente. Hg (y supongo que Git) no se dará cuenta ni se quejará durante los controles de rutina y solo escuchará sobre la corrupción cuando se queja de un repositorio corrupto cuando intenta usarlo de verdad. Malas noticias. Ojalá pudiera ser más específico sobre el problema y sus soluciones; Todavía estoy tratando de sacarme de este lío yo mismo.

También hay un proyecto de código abierto (una colección de scripts multiplataforma [Linux, Mac, Win]) que hace todos los detalles esenciales de la gestión del repositorio con un puñado (3-4) de comandos.

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

El uso de la muestra es:

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

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

Después de lo cual el uso normal de git:

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

Consulte el wiki del proyecto y los manuales para obtener referencias completas de comandos y tutoriales.

Guardo mis repositorios que no son de Github en Dropbox. Una advertencia que encontré fue la sincronización después de una reinstalación. Dropbox descargará primero los archivos más pequeños antes de pasar a los más grandes. No es un problema si comienzas de noche y vuelves después del fin de semana :-)

Mi hilo: http://forums.dropbox.com/topic.php?id=29984&replies=6

Ahora en 2014, he estado usando Git y Dropbox durante aproximadamente un año y medio sin problemas. Sin embargo, algunos puntos:

• Todas mis máquinas que usan Dropbox están en Windows, diferentes versiones (7 a 8) + 1 mac.
• No comparto el repositorio con otra persona, así que soy el único que lo modifica.
• git push empuja a un repositorio remoto, de modo que si alguna vez se corrompe, puedo recuperarlo fácilmente.
• Tenía que crear alias en C:\Usersla mklink /D link targetporque algunas bibliotecas se apuntaron a localizaciones absolutas.

Me gusta la respuesta más votada por Dan McNevin. Terminé haciendo la secuencia de comandos git demasiadas veces y decidí hacer un script. Asi que aqui esta:

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

El script solo requiere un nombre de proyecto. Generará un repositorio git ~/Dropbox/git/con el nombre especificado y enviará todo el contenido del directorio actual a la rama maestra de origen recién creada. Si se da más de un nombre de proyecto, se utilizará el argumento del nombre del proyecto más a la derecha.

Opcionalmente, el argumento del comando -r especifica la rama remota que se enviará al maestro de origen. La ubicación del maestro de origen del proyecto también se puede especificar con el argumento -m. Un archivo .gitignore predeterminado también se coloca en el directorio de sucursal remota. Los valores predeterminados del directorio y del archivo .gitignore se especifican en el script.

Otro enfoque:

Todas las respuestas hasta ahora, incluida la respuesta @Dan, que es la más popular, abordan la idea de usar Dropbox para centralizar un repositorio compartido en lugar de usar un servicio centrado en git como github, bitbucket, etc.

Pero, como la pregunta original no especifica qué significa realmente usar "Git y Dropbox juntos efectivamente", trabajemos en otro enfoque: "Usar Dropbox para sincronizar solo el árbol de trabajo".

El tutorial tiene estos pasos:

1. dentro del directorio del proyecto, uno crea un .gitdirectorio vacío (por ejemplo mkdir -p myproject/.git)

2. desincronice el .gitdirectorio en Dropbox. Si usa la aplicación de Dropbox: vaya a Preferencias, Sincronización y "elija carpetas para sincronizar", donde el .gitdirectorio debe quedar sin marcar. Esto eliminará el .gitdirectorio.

3. ejecutar git initen el directorio del proyecto

También funciona si .gitya existe, entonces solo haz el paso 2. Sin embargo, Dropbox mantendrá una copia de los archivos git en el sitio web.

El paso 2 hará que Dropbox no sincronice la estructura del sistema git, que es el resultado deseado para este enfoque.

¿Por qué uno usaría este enfoque?

• Los cambios que aún no se han presionado tendrán una copia de seguridad de Dropbox, y se sincronizarán en todos los dispositivos.

• En caso de que Dropbox arruine algo al sincronizar entre dispositivos, git statusy git diffserá útil para resolver las cosas.

• Ahorra espacio en la cuenta de Dropbox (el historial completo no se almacenará allí)

• Evita las preocupaciones planteadas por @dubek y @Ates en los comentarios sobre la respuesta de @ Dan, y las preocupaciones de @clu en otra respuesta .

La existencia de un control remoto en otro lugar (github, etc.) funcionará bien con este enfoque.

Trabajar en diferentes sucursales trae algunos problemas que deben ser atendidos:

• Un problema potencial es tener Dropbox (¿innecesariamente?) Sincronizando potencialmente muchos archivos cuando uno extrae diferentes ramas.

• Si dos o más dispositivos sincronizados de Dropbox tienen diferentes ramas desprotegidas, se pueden perder los cambios no comprometidos en ambos dispositivos,

Una forma de evitar estos problemas es usarlo git worktreepara mantener los pagos de sucursales en directorios separados.

Para mis 2 centavos, Dropbox solo tiene sentido para uso personal donde no desea molestarse en obtener un host de repositorio central. Para cualquier desarrollo profesional, probablemente creará más problemas de los que resolverá, como ya se mencionó varias veces en el hilo, Dropbox no está diseñado para este caso de uso. Dicho esto, un método perfectamente seguro para volcar repositorios en Dropbox sin ningún complemento o herramienta de terceros es usar paquetes. Tengo los siguientes alias en mi .gitconfigpara guardar la escritura:

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

Ejemplo:

# 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

Me he enfrentado a un problema similar y he creado un pequeño script para el mismo. La idea es usar Dropbox con Git de la manera más simple posible. Actualmente, he implementado rápidamente el código Ruby , y pronto agregaré más.

Se puede acceder al script en https://github.com/nuttylabs/box-git.

Sin usar herramientas de integración de terceros, podría mejorar un poco la condición y usar DropBox y otros servicios de disco en la nube similares, como SpiderOak con Git.

El objetivo es evitar la sincronización en el medio de las modificaciones de estos archivos, ya que puede cargar un estado parcial y luego volver a descargarlo, corrompiendo por completo su estado git.

Para evitar este problema, hice:

1. Agrupe mi índice git en un archivo usando git bundle create my_repo.git --all.
2. Establezca un retraso para la supervisión del archivo, por ejemplo, 5 minutos, en lugar de instantáneo. Esto reduce las posibilidades de que DropBox sincronice un estado parcial en medio de un cambio. También es de gran ayuda al modificar archivos en el disco de la nube sobre la marcha (como con las aplicaciones de toma de notas de guardado instantáneo).

No es perfecto ya que no hay garantía de que no volverá a estropear el estado git, pero ayuda y por el momento no tuve ningún problema.

En MacOS, también puede detener Dropbox, realizar sus cambios y luego volver a iniciar Dropbox. Estoy usando la siguiente combinación y estoy bastante contento con ella:

En ambos (su directorio local de proyectos gestionados por git y su repositorio de git remoto ubicado en Dropbox) ejecute el siguiente comando para deshabilitar el empaque automático (que es el principal problema con la sincronización de Dropbox)

git config --global gc.auto 0

Luego, de vez en cuando, comprima los repositorios con Dropbox deshabilitado. Por ejemplo, hago lo siguiente en mi bash-build-script cada vez que hago nuevas versiones de mis aplicaciones.

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